Which clients fully support P2SH and/or multisig ?

[Sergio_Demian_Lerner]

I'm reading Satoshi client code and Bitcoinj code. It seems to me that Satoshi supports given a P2SH address as destination, while Bitcoinj does not. On the other side, Satoshi client does not seems to provide multisig in its user interface.

Armory seems to support multisigs natively, but I cannot find support for P2SH (maybe is there somewhere).

Does anybody have a support matrix for each feature and each client ?

That would be awesome.

Thanks! Sergio.

[1714963130]

1714963130

[1714963130]

1714963130

[1714963130]

1714963130

[etotheipi]

I'm reading Satoshi client code and Bitcoinj code. It seems to me that Satoshi supports given a P2SH address as destination, while Bitcoinj does not. On the other side, Satoshi client does not seems to provide multisig in its user interface.

Armory seems to support multisigs natively, but I cannot find support for P2SH (maybe is there somewhere).

Does anybody have a support matrix for each feature and each client ?

That would be awesome.

Thanks! Sergio.

Armory has a ton of code for interpretting and handling multi-sig scripts, but nothing is actually usable yet.  It was implemented before P2SH existed (you might even find references in the code to OP_EVAL, which was the precursor to P2SH, and what was the leading contender when I wrote that code).

Armory needs a new wallet format in order to handle any of this "new" stuff.  Also, the blockchain utilities do not handle P2SH scripts.  This is all getting implemented in the next two major versions -- the first with new blockchain utilities for persistent DB storage, and the second with the new wallet format.  But I wouldn't consider anything "supported" yet, except Pay2PubkeyHash and Pay2PubKey scripts.

[mandros]

I tested some clients and web wallets to see if they were able to send bitcoins to a multisig address.

This were the results as of 21/06/2013:

Accepts a multisig address as destination (3...):
Bitcoin-qt
bitcoind
bitcoinspinner
bitcoinwallet.in
Coinbase
Electrum
inputs.io

Reports address as invalid or non-standard:
Android Wallet
Armory
Blockchain
Multibit
StrongCoin

[Mike Hearn]

These addresses are useless today because the only way to redeem them is to have all the keys loaded into the same Bitcoin-Qt.

P2SH is just a way to push data from outputs to inputs at the expense of making the chain bigger. It's not something I plan to support in bitcoinj anytime soon. Bitcoinj already supports multi-sig outputs in the sense that you can write apps that use them, send the signatures around, etc. As a feature it doesn't really make sense to expose to users raw - you need additional stuff on top anyway.

[Sergio_Demian_Lerner]

Thank you mandros for taking the time to research on this.

[jgarzik]

As far as I know, zero clients "fully support" multi-sig.

Simply creating multi-sig transactions often requires using some expert mode in the software, if the client supports it at all.  Consider that some balances are segmented into two categories:  (1) outputs you may spend (control all keys), and (2) outputs you might be able to spend (control M-of-N keys).  And, transactions must be passed around somehow in partially-signed state, which gathering signature from multiple parties.  There are several use-case and user-interface issues to be solved for useful workflow.

[Mike Hearn]

Yes, exactly. Multisig isn't a feature that really makes sense to expose directly. You build apps on top of it.

[TierNolan]

Yes, exactly. Multisig isn't a feature that really makes sense to expose directly. You build apps on top of it.

Is locktime actually supported at the moment?  I know replacement isn't.

[Peter Todd]

Yes, exactly. Multisig isn't a feature that really makes sense to expose directly. You build apps on top of it.

Is locktime actually supported at the moment?  I know replacement isn't.

Yes, works just fine, although we're probably going to need a soft-fork to fix some bad incentives made possible by time-based nLockTime. (by-height is fine) The first production code to use it will likely be for announce-commit sacrifices for jgarzik's identity protocol stuff.

Satoshi's implementation of replacement is one of the more dubious bits of design put in Bitcoin. It'll never be enabled the way Satoshi intended, and we've found that micropayment channels don't need sequence numbers anyway, and the non-sequence-based version is far more secure too. (no dependency on zero-conf)

[etotheipi]

...we've found that micropayment channels don't need sequence numbers anyway, and the non-sequence-based version is far more secure too

Can you elaborate on this?  Or point me to where the technicals are described?  I was not aware of this development.

[Mike Hearn]

I rather think it will be enabled and no it's not a bad design, and no the non-replacement based protocol is not more secure. The protocol we implemented is a hack that has some serious downsides in the user experience - it would work better and smoother with the original design.

Peter, I wish you would stop talking as if you are The Decider when it comes to Bitcoin. You routinely make pronouncements about what "will" or "will not" happen as if it's done and dusted when in reality these are just your personal opinions.

[Peter Todd]

...we've found that micropayment channels don't need sequence numbers anyway, and the non-sequence-based version is far more secure too

Can you elaborate on this?  Or point me to where the technicals are described?  I was not aware of this development.

Jeremy Spilman's solved it: http://permalink.gmane.org/gmane.comp.bitcoin.devel/2037 Bi-directional channels are easily done by setting up two channels in opposite directions.

Also see my note about using OP_DEPTH that I just posted to the -dev email list.

[Peter Todd]

Peter, I wish you would stop talking as if you are The Decider when it comes to Bitcoin. You routinely make pronouncements about what "will" or "will not" happen as if it's done and dusted when in reality these are just your personal opinions.

Standard disclaimer: Bitcoin is democratic and doesn't have deciders.

I'll get around to posting the summary of the discussion myself, luke-jr and gmaxwell had about nLockTime-by-time on -wizards soon.

[Mike Hearn]

You need more than bi-directional channels for things to work seamlessly, and obviously one:one channels are only one possibility.

The original design by Satoshi really is the best one. At some point, someone will have to fix the anti-DoS strategy in Bitcoin and at that point there aren't any reasons to not just enable the previous mechanism.

[jl2012]

...we've found that micropayment channels don't need sequence numbers anyway, and the non-sequence-based version is far more secure too

Can you elaborate on this?  Or point me to where the technicals are described?  I was not aware of this development.

Jeremy Spilman's solved it: http://permalink.gmane.org/gmane.comp.bitcoin.devel/2037 Bi-directional channels are easily done by setting up two channels in opposite directions.

Also see my note about using OP_DEPTH that I just posted to the -dev email list.

Sorry I don't understand

Code:

<height + n> OP_DEPTH OP_LESSTHAN
    IF 2 PK1 PK2 CHECKMULTISIG
    ELSE PK1 CHECKSIG
    ENDIF

OP_DEPTH "puts the number of stack items onto the stack." What's its function here?

[kjj]

Sorry I don't understand

Code:

<height + n> OP_DEPTH OP_LESSTHAN
    IF 2 PK1 PK2 CHECKMULTISIG
    ELSE PK1 CHECKSIG
    ENDIF

OP_DEPTH "puts the number of stack items onto the stack." What's its function here?

No, it puts the current depth of the transaction into the stack.  It makes the script stateful (often considered bad, see the discussion on the dev list).

This example says that you need to satisfy a multisig with two keys, until the transaction reaches a certain depth, when it can be redeemed by one script.  The idea is that it removes the risk of the counterparty disappearing by giving the first guy the ability to reclaim his money in the future.

[Peter Todd]

Sorry I don't understand

Code:

<height + n> OP_DEPTH OP_LESSTHAN
    IF 2 PK1 PK2 CHECKMULTISIG
    ELSE PK1 CHECKSIG
    ENDIF

OP_DEPTH "puts the number of stack items onto the stack." What's its function here?

Good catch.

We've been using the term "OP_DEPTH" to talk about an idea to do a soft-fork to allow a transaction to query the block height of the block including the transaction in some way. I forgot there already is an OP_DEPTH opcode, which makes it a horrible name.

I'll call these hypothetical opcodes OP_BLOCKHEIGHT, OP_TXOUTHEIGHT and OP_TXOUTDEPTH in the future to be clear.

Sorry about that.

[Peter Todd]

This example says that you need to satisfy a multisig with two keys, until the transaction reaches a certain depth, when it can be redeemed by one script.  The idea is that it removes the risk of the counterparty disappearing by giving the first guy the ability to reclaim his money in the future.

To be clear the protocol implemented now is that a time-locked refund tx is created when tx1 is created that returns the money in the future, but ultimately there will always be a short time window where the counter-party can vanish leaving the funds locked. Jeremy Spilman's solution was to have the counter-party also include some funds, so that their funds would be locked as well so the counter-party has strong incentives to not allow this to happen; I'm not sure what bitcoinj has implemented.

[etotheipi]

This example says that you need to satisfy a multisig with two keys, until the transaction reaches a certain depth, when it can be redeemed by one script.  The idea is that it removes the risk of the counterparty disappearing by giving the first guy the ability to reclaim his money in the future.

To be clear the protocol implemented now is that a time-locked refund tx is created when tx1 is created that returns the money in the future, but ultimately there will always be a short time window where the counter-party can vanish leaving the funds locked. Jeremy Spilman's solution was to have the counter-party also include some funds, so that their funds would be locked as well so the counter-party has strong incentives to not allow this to happen; I'm not sure what bitcoinj has implemented.

How can the counter-party vanishing affect this?  You get the refund (Tx2) signed by the payee before you (payor) sign the funding transaction (Tx1).   That essentially makes the whole operation atomic:  either all parties get their money into an escrow that automatically returns to the payor if one of the parties disappears... or nothing happens.

[kjj]

This example says that you need to satisfy a multisig with two keys, until the transaction reaches a certain depth, when it can be redeemed by one script.  The idea is that it removes the risk of the counterparty disappearing by giving the first guy the ability to reclaim his money in the future.

To be clear the protocol implemented now is that a time-locked refund tx is created when tx1 is created that returns the money in the future, but ultimately there will always be a short time window where the counter-party can vanish leaving the funds locked. Jeremy Spilman's solution was to have the counter-party also include some funds, so that their funds would be locked as well so the counter-party has strong incentives to not allow this to happen; I'm not sure what bitcoinj has implemented.

I was browsing the forums while ignoring a boring presentation.  I didn't read the whole exchange in detail, just enough to confirm my guess at the function of the script presented.

As you may have noticed from my post, I'm not as willing to handwave over adding state to transactions.  I follow the argument about checking history as well as confirmations.  I think that it might be too complicated to make reasonably accurate estimates of security once branching is added.