Bitcoin Forum
April 20, 2024, 04:26:14 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1] 2 »  All
  Print  
Author Topic: Which clients fully support P2SH and/or multisig ?  (Read 5059 times)
Sergio_Demian_Lerner (OP)
Hero Member
*****
expert
Offline Offline

Activity: 549
Merit: 608


View Profile WWW
July 12, 2013, 05:57:22 PM
Merited by ABCbits (1)
 #1

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.
1713587174
Hero Member
*
Offline Offline

Posts: 1713587174

View Profile Personal Message (Offline)

Ignore
1713587174
Reply with quote  #2

1713587174
Report to moderator
Even in the event that an attacker gains more than 50% of the network's computational power, only transactions sent by the attacker could be reversed or double-spent. The network would not be destroyed.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1713587174
Hero Member
*
Offline Offline

Posts: 1713587174

View Profile Personal Message (Offline)

Ignore
1713587174
Reply with quote  #2

1713587174
Report to moderator
1713587174
Hero Member
*
Offline Offline

Posts: 1713587174

View Profile Personal Message (Offline)

Ignore
1713587174
Reply with quote  #2

1713587174
Report to moderator
etotheipi
Legendary
*
expert
Offline Offline

Activity: 1428
Merit: 1093


Core Armory Developer


View Profile WWW
July 12, 2013, 06:06:29 PM
Merited by ABCbits (1)
 #2

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.

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
mandros
Newbie
*
Offline Offline

Activity: 21
Merit: 0


View Profile
July 13, 2013, 08:44:38 AM
Last edit: July 13, 2013, 08:58:07 AM by mandros
 #3

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
Legendary
*
expert
Offline Offline

Activity: 1526
Merit: 1128


View Profile
July 13, 2013, 12:43:07 PM
 #4

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 (OP)
Hero Member
*****
expert
Offline Offline

Activity: 549
Merit: 608


View Profile WWW
July 13, 2013, 01:03:06 PM
 #5

Thank you mandros for taking the time to research on this.
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1596
Merit: 1091


View Profile
July 17, 2013, 09:11:03 AM
 #6

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.


Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526
Merit: 1128


View Profile
July 17, 2013, 09:34:56 AM
 #7

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

Activity: 1232
Merit: 1083


View Profile
July 17, 2013, 10:56:13 AM
 #8

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.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
Peter Todd
Legendary
*
expert
Offline Offline

Activity: 1120
Merit: 1149


View Profile
July 17, 2013, 11:23:07 AM
 #9

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
Legendary
*
expert
Offline Offline

Activity: 1428
Merit: 1093


Core Armory Developer


View Profile WWW
July 17, 2013, 06:07:00 PM
 #10

...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.

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526
Merit: 1128


View Profile
July 18, 2013, 10:41:09 AM
 #11

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
Legendary
*
expert
Offline Offline

Activity: 1120
Merit: 1149


View Profile
July 18, 2013, 11:15:56 AM
 #12

...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
Legendary
*
expert
Offline Offline

Activity: 1120
Merit: 1149


View Profile
July 18, 2013, 11:24:10 AM
 #13

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
Legendary
*
expert
Offline Offline

Activity: 1526
Merit: 1128


View Profile
July 18, 2013, 01:29:44 PM
 #14

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
Legendary
*
Offline Offline

Activity: 1792
Merit: 1092


View Profile
July 18, 2013, 03:40:31 PM
 #15

...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?

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
kjj
Legendary
*
Offline Offline

Activity: 1302
Merit: 1024



View Profile
July 18, 2013, 03:54:41 PM
 #16


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.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
Peter Todd
Legendary
*
expert
Offline Offline

Activity: 1120
Merit: 1149


View Profile
July 18, 2013, 04:03:33 PM
 #17

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
Legendary
*
expert
Offline Offline

Activity: 1120
Merit: 1149


View Profile
July 18, 2013, 04:14:32 PM
 #18

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
Legendary
*
expert
Offline Offline

Activity: 1428
Merit: 1093


Core Armory Developer


View Profile WWW
July 18, 2013, 04:18:28 PM
 #19

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.

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
kjj
Legendary
*
Offline Offline

Activity: 1302
Merit: 1024



View Profile
July 18, 2013, 04:33:00 PM
 #20

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.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
Pages: [1] 2 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!