Bitcoin Forum
April 26, 2024, 01:33:41 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: What do alt coin developers think about BIP 11/12/13 ?  (Read 1744 times)
finway (OP)
Hero Member
*****
Offline Offline

Activity: 714
Merit: 500


View Profile
November 03, 2011, 11:47:35 AM
Last edit: November 03, 2011, 12:40:54 PM by finway
 #1

Or just wait & copy the code ?  Wink

1714095221
Hero Member
*
Offline Offline

Posts: 1714095221

View Profile Personal Message (Offline)

Ignore
1714095221
Reply with quote  #2

1714095221
Report to moderator
No Gods or Kings. Only Bitcoin
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1714095221
Hero Member
*
Offline Offline

Posts: 1714095221

View Profile Personal Message (Offline)

Ignore
1714095221
Reply with quote  #2

1714095221
Report to moderator
Remember remember the 5th of November
Legendary
*
Offline Offline

Activity: 1862
Merit: 1011

Reverse engineer from time to time


View Profile
November 03, 2011, 12:24:10 PM
 #2

Wait what? What in the world is BIP?

BTC:1AiCRMxgf1ptVQwx6hDuKMu4f7F27QmJC2
finway (OP)
Hero Member
*****
Offline Offline

Activity: 714
Merit: 500


View Profile
November 03, 2011, 12:38:35 PM
 #3

Bitcoin Improvement Proposals

https://en.bitcoin.it/wiki/Bitcoin_Improvement_Proposals

cereal7802
Newbie
*
Offline Offline

Activity: 57
Merit: 0


View Profile
November 03, 2011, 12:40:21 PM
 #4

shouldn't this go somewhere else? if its a bitcoin proposal surely it is not an alt coin?
finway (OP)
Hero Member
*****
Offline Offline

Activity: 714
Merit: 500


View Profile
November 03, 2011, 12:47:51 PM
 #5

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

coblee
Donator
Legendary
*
Offline Offline

Activity: 1653
Merit: 1286


Creator of Litecoin. Cryptocurrency enthusiast.


View Profile
November 03, 2011, 04:17:52 PM
 #6

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?

Gavin Andresen
Legendary
*
Offline Offline

Activity: 1652
Merit: 2216


Chief Scientist


View Profile WWW
November 03, 2011, 09:28:50 PM
 #7

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)

How often do you get the chance to work on a potentially world-changing project?
coblee
Donator
Legendary
*
Offline Offline

Activity: 1653
Merit: 1286


Creator of Litecoin. Cryptocurrency enthusiast.


View Profile
November 04, 2011, 12:31:41 AM
 #8

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.

Gavin Andresen
Legendary
*
Offline Offline

Activity: 1652
Merit: 2216


Chief Scientist


View Profile WWW
November 04, 2011, 09:10:38 PM
 #9

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 <nrequired> <'["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 <nrequired> 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://bitcointalk.org/index.php?topic=39471.msg597785#msg597785  for a proposal on how to do that.




How often do you get the chance to work on a potentially world-changing project?
sd
Hero Member
*****
Offline Offline

Activity: 730
Merit: 500



View Profile
November 05, 2011, 01:48:29 PM
 #10


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

Activity: 112
Merit: 11

Hillariously voracious


View Profile
November 07, 2011, 12:31:39 PM
 #11

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

Geist Geld, the experimental cryptocurrency, is ready for yet another SolidCoin collapse Wink

Feed the Lolcust!
NMC: N6YQFkH9Gn9CTm4mpGwuLB5zLzqWTWFw67
BTC: 15F8xbgRBA1XZ4hmtdFDUasroa2A5rYg8M
GEG: gK5Lx6ypWgr69Gw9yGzE6dsA7kcuCRZRK
Pages: [1]
  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!