3

An N-of-M multisignature Transaction requires to be signed by N addresses to be a valid transaction. I would like to know whether the Bitcoin Protocol would transmit a Transaction with less than N signatures through the Network in order for it to reach the other parties holding the remaining addresses, or would it be rejected?

The problem essentially boils down to whether one can reliably use the Bitcoin Network to initiate N-of-M Transactions and let them reach the other parties on their Clients, or would the Transaction need to be transmitted outside of the Network first, signed by the N addresses, and only then broadcast through the Network?

ThePiachu
  • 42,931
  • 25
  • 138
  • 347
  • 1
    I did some n-of-m transactions on Testnet. It was real hard work to get **signrawtransaction** to return Complete. I believe that it is required to be able to broadcast the transaction. – Jonas Oestman Nov 19 '13 at 17:44
  • @JonasOestman `signrawtransaction` is one problem, figuring out whether Bitcoin is willing to transmit partially signed transactions is another. Bitcoind also doesn't like reporting transactions going into multisig addresses, which makes things even more awkward. – ThePiachu Nov 19 '13 at 19:30

1 Answers1

3

Mike Hearn talks in his speech about the future of bitcoin and mentions subchannels when doing micro payments, is this what you are looking after?

When i try this in Testnet getreceivedbyaddress does show the amount sent to the multisig address, but listunspent does not. So even if listaddressgroupings include the multisig address, you still need to know the txid to be able to spend that prev_output.

if i try to send a tx with only 1 signature, this is what i get in the log:

  • ThreadRPCServer method=sendrawtransaction
  • ERROR: CScriptCheck() : 4378d77e5d VerifySignature failed
  • ERROR: CTxMemPool::accept() : ConnectInputs failed 4378d77e5d

and with 2 signatures (Complete):

  • ThreadRPCServer method=sendrawtransaction
  • AddToWallet 470a194f21 new
  • keypool reserve 9
  • keypool keep 9
  • CTxMemPool::accept() : accepted 470a194f21 (poolsz 5)
  • AddToWallet 470a194f21
  • received getdata for: tx 470a194f21

txid is also returned 470a194f21 by the client.

My answer is:

No, the mempool will not work as a subchannel (right now, if it ever was indended)

Jonas Oestman
  • 484
  • 3
  • 12
  • MyWallet must have used some sort of subchannel for their **escrow** implementation, but it gone now http://web.archive.org/web/20130820060529/https://blockchain.info/wallet/escrow – Jonas Oestman Nov 22 '13 at 05:41