<p>Mike Hearn talks in his <a href="http://www.youtube.com/watch?v=mD4L7xDNCmA" rel="nofollow" title="Mike Hearn - Bitcoin 2012">speech</a> about the future of bitcoin and mentions subchannels when doing <a href="https://en.bitcoin.it/wiki/Contracts#Example_7%3a_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party" rel="nofollow">micro payments</a>, is this what you are looking after?</p>

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

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

<ul>
<li>ThreadRPCServer method=sendrawtransaction</li>
<li>ERROR: CScriptCheck() : 4378d77e5d VerifySignature failed</li>
<li>ERROR: CTxMemPool::accept() : ConnectInputs failed 4378d77e5d</li>
</ul>

<p>and with 2 signatures (Complete):</p>

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

<p>txid is also returned <a href="http://blockexplorer.com/testnet/tx/470a194f2194e0222583c0d7d852fba34ec03863161bd524fb7ccd7d9f594c3f" rel="nofollow" title="470a194f21">470a194f21</a> by the client.</p>

<p><strong>My answer is:</strong></p>

<p>No, the <strong>mempool</strong> will not work as a subchannel (right now, if it ever was indended)</p>

CC BY-SA 3.0
2013-11-22T05:41:03.893Z
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
CC BY-SA 3.0
2013-11-22T05:31:10.877Z
2013-11-22T05:31:10.877Z
Jonas Oestman
<p>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?</p>

<p>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?</p>

CC BY-SA 3.0
2013-11-19T17:44:45.833Z
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
CC BY-SA 3.0
2013-11-19T19:30:46.067Z
@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
<network><multi-signature><data-security>
Is a multisignature transaction propagated through the Network before it accumulates enough signatures?
ThePiachu
# Is a multisignature transaction propagated through the Network before it accumulates enough signatures?

(Asked by: username_0 on 2013-11-19)

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?

**Tags:** network, multi-signature, data-security

> **Comments:**
> **username_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.  
> **username_0**: @username_1 `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.  

---

## 1 answers

### Answer by username_1 on 2013-11-22. Score: 3 | Accepted answer

Mike Hearn talks in his [speech](http://www.youtube.com/watch?v=mD4L7xDNCmA "Mike Hearn - Bitcoin 2012") about the future of bitcoin and mentions subchannels when doing [micro payments](https://en.bitcoin.it/wiki/Contracts#Example_7%3a_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party), 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](http://blockexplorer.com/testnet/tx/470a194f2194e0222583c0d7d852fba34ec03863161bd524fb7ccd7d9f594c3f "470a194f21") by the client.

**My answer is:**

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

> **Comments:**
> **username_1**: 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  

---

