Author

Topic: What do alt coin developers think about BIP 11/12/13 ? (Read 1768 times)

member
Activity: 112
Merit: 11
Hillariously voracious
First and foremost, I'd like to say that I like multisign on general principle and invite people to try out various ways of doing it on GG (it allows nonstandard by default).

However, I doubt that multisign in its most classical "(n+1) escrow" scenario is just as useful as it is usually portrayed to be, and I am convinced that lack of it is not a massive barrier to adoption.

As for op-eval specifically, I am quite worried about moving the fee burden to the receiving end of the transaction, as it seems to me that it would make the "unpredictable transaction fee" blight worse, but I think I'd best discuss this with Theymos - he's quite a smart guy, so it is possible that he is right, shifting fees to receiver is awesome, and he will convince me to that effect.


Multisign sounds like a huge benefit. As far as I'm aware every company that does Internet banking currently needs 2 signatures to transfer money. One from the finance guy who actually works out what to send to who and one from management who should verify the finance guy isn't transferring the money to his personal account.

It seems to me that since any reasonable company with more than one man involved Smiley and a wallet teeming with hundreds of thousands of bitcoinses would have the machine the wallet resides on pretty buttoned up and gapped, so the rules regarding necessity for multiparty approval of transactions can be enforced on the level of "walletbox" authentication (with possible reasonabl-ish requirement of at least one decision maker to be physically present at the walletbox office if the sum is really huge)

So lack of multisign is hardly an adoption boundary (besides, AFAIK, painpal, libreserve, pecunix et al don't explicitly allow multiparty confirmation as well, and that does not seem to hamper their adoption all that much).

If anything, finding a way to split private keys in a manner that several different devices would have to cooperate to create a "normal" BTC transaction would be closer to what a corporate "multiparty validation" entails.

Lower trust escrow and "wallet lockdown" services are kind of neat, but not "we need it NOW or else" kind of neat.

P.S.:
It would be also neat to have a separate address format (different addressversions or perhaps even a new-ish address format specially for "exotic" stuff).

It would be also neat to have frugal (as in, puts only a little bit of info into the blockchain) transaction earmarking as well as intra-network messaging (incidentally, those are two things I hope to eventually implement in Tenebrix since they are needed for a website-less laundryStrong Transaction Decorrelator system)

P.P.S.: Personally, I love Gavin's Hidden Send, but sadly this type of custom transaction has turned out to be DOA. I would really love to see it (or a functional equivalent) to "come back", maybe with some nifty improvements (a man can dream right? Wink ) but that would likely require a large (and dangerous) scripting language overhaul...
sd
hero member
Activity: 730
Merit: 500

Multisign sounds like a huge benefit. As far as I'm aware every company that does Internet banking currently needs 2 signatures to transfer money. One from the finance guy who actually works out what to send to who and one from management who should verify the finance guy isn't transferring the money to his personal account.

Also using this for escrow saves us from the serious problem of having to trust the escrow organization.

However more complex solutions carry a greater risk of failure. Using this means there are now more ways to lose access to your coins.
legendary
Activity: 1652
Merit: 2301
Chief Scientist
I will look into adding this to Litecoin. Gavin, what are the gotchas? Is there a possibility of a chain fork from this change? And what I should I pay attention to when testing this on the testnet. And let me know if you want to help test it.
See BIP 12, the Backwards Compatibility section, for gotchas-- block chain forks are possible if you're not careful. They won't happen by accident, but if you assume there is an attacker that just wants to cause inconvenience by forking the chain then you have to roll-out the change carefully.

To test on testnet:

Apply the patch. Then use the extended 'validateaddress' RPC command that is part of the patch to get public keys for several of your bitcoin addresses (use getnewaddress to generate new ones if you need to).

Combine those public keys into multi-signature addresses using the new addmultisig RPC command:
   addmultisigaddress <'["key","key"]'> [account]

So for a 2-of-3 escrow you'd call:
   addmultisigaddress 2 '["...pkey1...","...pkey2...","...pkey3..."]'

It returns a multisignature bitcoin address.

You'd do that on all the machines involved in the escrow transaction.

To fund that multisignature address, you just use the normal sendtoaddress (or sendmany or sendfrom) RPC commands, using the address returned from addmultisigaddress.

To spend those funds... more patches are needed.  You CAN actually spend them if you have ALL the private keys in your wallet; if you do, then the multisignature transaction is treated just like any other transaction you've received, and will show up as part of your wallet's balance, in listtransactions output, etc.

Modifying the patch so that you can spend them if you have keys is probably the right thing to do, although the security implications of that for shared-wallet providers needs to be carefully thought through. And in almost all of the real multisignature use cases, a RPC calls to create and sign partially-signed transactions is the right thing to do, NOT importing private keys from the other people involved in the transaction. See: https://gist.github.com/1321518   and  https://bitcointalksearch.org/topic/m.597785  for a proposal on how to do that.



donator
Activity: 1654
Merit: 1351
Creator of Litecoin. Cryptocurrency enthusiast.
I'd like to see one or more of the alt chains take:
  https://github.com/gavinandresen/bitcoin-git/tree/op_eval

... and start supporting OP_EVAL, multisignature transactions, and the new bitcoin address type.

(and thanks to coblee- he did help flesh out the ideas)

FYI, fixed above.

I will look into adding this to Litecoin. Gavin, what are the gotchas? Is there a possibility of a chain fork from this change? And what I should I pay attention to when testing this on the testnet. And let me know if you want to help test it.
legendary
Activity: 1652
Merit: 2301
Chief Scientist
I'd like to see one or more of the alt chains take:
  https://github.com/gavinandresen/bitcoin-git/tree/op_eval

... and start supporting OP_EVAL, multisignature transactions, and the new bitcoin address type.

(and thanks to coblee- he (she?) did help flesh out the ideas)
donator
Activity: 1654
Merit: 1351
Creator of Litecoin. Cryptocurrency enthusiast.
If you looked at the initial multisign proposal on github, you will see that I helped Gavin flesh out the idea:

https://gist.github.com/39158239e36f6af69d6f

So I'm looking forward to Bitcoin getting multisign soon. I'm not sure what exactly you are asking though. Are you wondering if the alt coins should consider implementing first to help test them out?
hero member
Activity: 714
Merit: 500
shouldn't this go somewhere else? if its a bitcoin proposal surely it is not an alt coin?
I think i mentioned alt coin .  Wink
newbie
Activity: 57
Merit: 0
shouldn't this go somewhere else? if its a bitcoin proposal surely it is not an alt coin?
hero member
Activity: 714
Merit: 500
legendary
Activity: 1862
Merit: 1011
Reverse engineer from time to time
Wait what? What in the world is BIP?
hero member
Activity: 714
Merit: 500
Or just wait & copy the code ?  Wink
Jump to: