Bitcoin Forum
December 11, 2016, 02:42:50 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2] 3 »  All
  Print  
Author Topic: BIP 22?  (Read 3834 times)
btc_artist
Full Member
***
Offline Offline

Activity: 154


Bitcoin!


View Profile WWW
February 01, 2012, 06:10:24 PM
 #21

I've said before I support Gavin and BIP 16.  That being said, I'm curious if Gavin has any further comments on the technical merit of Mike's suggestion.

BTC: 1CDCLDBHbAzHyYUkk1wYHPYmrtDZNhk8zf
LTC: LMS7SqZJnqzxo76iDSEua33WCyYZdjaQoE
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481424170
Hero Member
*
Offline Offline

Posts: 1481424170

View Profile Personal Message (Offline)

Ignore
1481424170
Reply with quote  #2

1481424170
Report to moderator
1481424170
Hero Member
*
Offline Offline

Posts: 1481424170

View Profile Personal Message (Offline)

Ignore
1481424170
Reply with quote  #2

1481424170
Report to moderator
Technomage
Legendary
*
Offline Offline

Activity: 1624


Affordable Physical Bitcoins - Denarium.com


View Profile WWW
February 01, 2012, 06:23:50 PM
 #22

I don't get how this causes a worse split than the other BIPs since they all require the majority of miners to update.  Doesn't the BIP 17 stealing bot essentially means implementing that proposal requires everyone to update, too?
The split is different because with BIP16 only the miners are forced to upgrade. With BIP22 there is a hard split between new clients and old clients, it's not just about the miners. However Casascius is saying that it doesn't actually matter that there is a split, that it's safe for people to continue to use the old clients. That is the big issue right now.

I don't really get it though, I mean if user x and y are part of the "old chain" and user x sends user y some coins after the split, the old fashioned way of course, and then these users upgrade their clients, does the new chain include everything that's happening in the old chain but not the other way around? Is the newly received money still in user y's wallet after he upgrades? Probably stupid questions but I would like to understand this better.

Denarium - Leading Physical Bitcoin Manufacturer - Special Xmas deals now live!
casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1344


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
February 01, 2012, 06:36:10 PM
 #23

I don't really get it though, I mean if user x and y are part of the "old chain" and user x sends user y some coins after the split, the old fashioned way of course, and then these users upgrade their clients, does the new chain include everything that's happening in the old chain but not the other way around? Is the newly received money still in user y's wallet after he upgrades? Probably stupid questions but I would like to understand this better.

I would expect the answer to be yes.  In this scenario, both the "old" and "new" clients are still communicating with one another, they just disagree on which blocks are valid.  But transactions and coins are completely compatible, except ones that have been involved in multisig transactions - from the view of the old clients, multisig coins are "lost" coins.  Old clients will always reject spends that are only recognized on the new fork.

If x sends money to y on an old client, it can only be with coins that came through a progeny of transactions that would have been acceptable to both forks (no multisig anywhere in history).  If multisig were anywhere in the history, x wouldn't see these coins to begin with (they're "lost" after all), and wouldn't ever be able to send them.

When client x sends coins to y, client x doesn't necessarily intend to send his transaction to the new fork he doesn't know about.  But since "sends" on both forks look identical, and old clients are still talking to new clients, the two forks essentially cross-contaminate each other (beneficially) with each other's unconfirmed transactions, which results in every unconfirmed transaction that would be considered valid by both clients making it into both forks independently.

Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper wallets instead.
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
February 01, 2012, 06:40:45 PM
 #24

No, bad idea, two chains cannot peacefully coexist for more than a few dozen blocks, they would eventually make a complete mess out of users' wallets.


How often do you get the chance to work on a potentially world-changing project?
casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1344


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
February 01, 2012, 06:47:10 PM
 #25

...they would eventually make a complete mess out of users' wallets.

As I understand it, it's a mess that would be completely remedied simply by having the newer version of the client rescan the wallet against the block chain once upon upgrade from the point of the fork (something I would expect it would do anyway by itself, since it would see what amounts to a normal chain reorg the moment once it suddenly becomes accepting of a tall chain of blocks it had rejected before).  The most critical entries in a wallet (keys, address book entries, settings) would be uninvolved in any mess, the rest I expect would be rebuilt without user interaction by the code already in the project.

I don't think I suggest that the chains peacefully coexist by design - the old chain is "old" and "dead" for a reason.  I suggest only that under what I proposed, the "old" chain would continue to function just well enough to reject spends of coins that had already been spent in the new chain.

Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper wallets instead.
interlagos
Hero Member
*****
Offline Offline

Activity: 497


View Profile
February 01, 2012, 06:53:09 PM
 #26

What actually happens if user sends coins from old client into BIP16/17 multisig address?
Do they just disappear in a black hole? Or does the old client generates error message?

Some people with old clients might not be able to recognize new addresses and send coins by mistake.
casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1344


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
February 01, 2012, 06:56:32 PM
 #27

What actually happens if user sends coins from old client into BIP16/17 multisig address?
Do they just disappear in a black hole? Or does the old client generates error message?

Some people with old clients might not be able to recognize new addresses and send coins by mistake.

This proposal is mutually exclusive of BIP 16/17.  If BIP 16 or BIP 17 is accepted, this proposal becomes unnecessary and will not be implemented.  Same vice versa.

However, if the question is, will old clients be able to send to new multisig addresses, the answer is YES, and the transaction will work correctly.  That's because a sender's client doesn't even know he is sending to a multisig address because it is still just a normal bitcoin address.  The transaction is identified as multisig much later when those coins are respent.  So, old clients can't see incoming transactions from multisig clients, but they can send coins to multisig clients (including their multisig addresses) just fine.

No coins are ever "lost" with this proposal.  When I say "lost", I simply mean that the old client sees multisig coins as "lost" only because it can't understand how they are being spent, and because it's impossible to respend them in a way that the old client will accept as an incoming transaction.  As soon as the user upgrades, the new client understands the new spending rules and they are no longer "lost".

Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper wallets instead.
Costia
Newbie
*
Offline Offline

Activity: 28



View Profile
February 01, 2012, 06:59:55 PM
 #28

cas, if you are proposing to do a chainsplit, then why not implement the 3 parts signature, why not implement the "perfect solution"?
casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1344


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
February 01, 2012, 07:06:20 PM
 #29

cas, if you are proposing to do a chainsplit, then why not implement the 3 parts signature, why not implement the "perfect solution"?

Three-part and m-of-n signatures are completely supported in my proposal.  I have provided specific examples in my proposal.

Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper wallets instead.
interlagos
Hero Member
*****
Offline Offline

Activity: 497


View Profile
February 01, 2012, 07:10:22 PM
 #30

What actually happens if user sends coins from old client into BIP16/17 multisig address?
Do they just disappear in a black hole? Or does the old client generates error message?

Some people with old clients might not be able to recognize new addresses and send coins by mistake.

This proposal is mutually exclusive of BIP 16/17.  If BIP 16 or BIP 17 is accepted, this proposal becomes unnecessary and will not be implemented.  Same vice versa.

However, if the question is, will old clients be able to send to new multisig addresses, the answer is YES, and the transaction will work correctly.  That's because a sender's client doesn't even know he is sending to a multisig address because it is still just a normal bitcoin address.  The transaction is identified as multisig much later when those coins are respent.  So, old clients can't see incoming transactions from multisig clients, but they can send coins to multisig clients (including their multisig addresses) just fine.

No coins are ever "lost" with this proposal.  When I say "lost", I simply mean that the old client sees multisig coins as "lost" only because it can't understand how they are being spent, and because it's impossible to respend them in a way that the old client will accept as an incoming transaction.  As soon as the user upgrades, the new client understands the new spending rules and they are no longer "lost".

I understand that it works fine with BIP22, my concern was that if we go with BIP16 only, what would happen then?
Edit: Ok I re-read the answer and now understand that sending coins from an old client should work with any of the BIPs.
Costia
Newbie
*
Offline Offline

Activity: 28



View Profile
February 01, 2012, 07:11:02 PM
 #31

so basically you are saying: forget about backward compatibility and implement the best solution without any constraints?
casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1344


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
February 01, 2012, 07:20:28 PM
 #32

so basically you are saying: forget about backward compatibility and implement the best solution without any constraints?

That decision is up to Gavin.

I don't think any of the solutions are backwards compatible - all of them require everyone to upgrade to continue using Bitcoin, even if they aren't interested in multisig.  The way I see it, the discussion of backward compatibility really only pertains to the question of what will happen to users that don't upgrade.  The goal is not to ensure they can continue to use their old client (which I understand is true of all multisig proposals including 16 and 17).  Rather, the goal is to ensure that they won't lose coins, and that they won't be victimized by double spends from clever attackers who spend their coins once with the new version and once again with the old clients who can't see the coins are already spent.

Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper wallets instead.
casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1344


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
February 01, 2012, 07:29:17 PM
 #33

You should be able to use your present wallet but would probably be required to upgrade your client.

No, you don't have to upgrade your client to receive coins from somebody using a BIP 16 multisignature wallet.

This plucked from another thread - to the extent this is true, I stand corrected on the point that someone could continue to use their old client.  (assuming of course that the person using a BIP 16 multisignature wallet is spending coins they actually own, since it would appear old client can't determine this for itself).

Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper wallets instead.
bulanula
Hero Member
*****
Offline Offline

Activity: 518



View Profile
February 01, 2012, 07:31:03 PM
 #34

so basically you are saying: forget about backward compatibility and implement the best solution without any constraints?

IMHO this seems the best way of doing it but make sure everyone can "convert" ( yeah I know oversimplified ) their BTC from the old type to the new type.

But at this rate of developing and "screw deadlines" attitude and petty fights between Gavin and Luke ( and deepshit refusing to accept any change ) we can say bye bye to multisig for now Angry

Yeah, even the old banking system and Benny printing his toilet paper is better than this chaos Undecided

Where is Satoshi when we need him ? Why has he not thought of this ?
dayfall
Sr. Member
****
Offline Offline

Activity: 312



View Profile
February 01, 2012, 08:09:17 PM
 #35

Wouldn't the old chain stop growing?  I mean, the large majority of miners and the pools will switch over very quickly.  Anyone using the old client should fairly abruptly stop getting confirmations, right?   If coordinated, this would be very abrupt.
interlagos
Hero Member
*****
Offline Offline

Activity: 497


View Profile
February 01, 2012, 08:48:15 PM
 #36

Wouldn't the old chain stop growing?  I mean, the large majority of miners and the pools will switch over very quickly.  Anyone using the old client should fairly abruptly stop getting confirmations, right?   If coordinated, this would be very abrupt.

Yes it looks like the old chain will just stall. It might be a good thing if we want people to upgrade their clients.
They will see that something is wrong, go to the official site and boom there is a new client with the message to upgrade.
Not this time maybe but in the future, when we really need to fork.
dooglus
Legendary
*
Offline Offline

Activity: 2002



View Profile
February 02, 2012, 12:34:03 AM
 #37

No, bad idea, two chains cannot peacefully coexist for more than a few dozen blocks, they would eventually make a complete mess out of users' wallets.

It took me a while to understand why this would be the case, but perhaps it's the following:

The 'old' chain will grow independently of the 'new' chain, generating 50 BTC per block which will spread to users of the old chain, and which they will believe is 'real' BTC.  Then when they upgrade to a BIP 22 client, they find that the coins generated on the old fork are no longer valid.

ie. the transactions look valid on both forks in terms of their format, but not in terms of their coinbases.

Then again doesn't it take something like 100 blocks before newly minted coins are spendable?  In which case I'm back to not understanding how BIP 22's chain split would "make a complete mess out of users' wallets" within "a few dozen blocks".

casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1344


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
February 02, 2012, 01:17:36 AM
 #38

Then again doesn't it take something like 100 blocks before newly minted coins are spendable?  In which case I'm back to not understanding how BIP 22's chain split would "make a complete mess out of users' wallets" within "a few dozen blocks".

What you are saying sounds right to me.  None of the pools will be mining the old chains, it will only be at most some solo miners.  It will also take an awfully long time, if it ever happens, for the generations to mature without any mining power to support what will remain the original difficulty.

Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper wallets instead.
Steve
Hero Member
*****
Offline Offline

Activity: 868



View Profile WWW
February 02, 2012, 01:30:02 AM
 #39

No, bad idea, two chains cannot peacefully coexist for more than a few dozen blocks, they would eventually make a complete mess out of users' wallets.
In the future, what you'd want to help manage a necessary chain split are nodes that will only accept transactions deemed valid in multiple chains.  Certainly, once a new set of validation rules are largely agreed upon, miners will switch over quickly (because if they stay on a dying chain they would be mining blocks with worthless coin base transactions).  A chain split may actually be easier to manage in the future than we can imagine today.  As thin client wallets proliferate and rely on a trusted point of presence on the bitcoin network, the full nodes that provide access to the bitcoin network can help ensure that only valid coins are ever accepted into wallets (possibly validating against multiple chains for short periods of time during a transition).  The reason you would want to validate against both the old and the new chain for a short period of time is that you want to make sure the transition actually occurs and you reach the critical mass to make the transition "stick."  If you only accept coins that are valid on both chains for that transition period, you can rest assured that no matter whether the transition is successful or not, all of the coins in your wallet will be spendable.

(gasteve on IRC) Does your website accept cash? https://bitpay.com
dooglus
Legendary
*
Offline Offline

Activity: 2002



View Profile
February 02, 2012, 08:50:53 AM
 #40

But since "sends" on both forks look identical, and old clients are still talking to new clients, the two forks essentially cross-contaminate each other (beneficially) with each other's unconfirmed transactions, which results in every unconfirmed transaction that would be considered valid by both clients making it into both forks independently.

What if I don't publish the transaction in which I spend an old coin, but wait until I can mine a block containing the transaction for myself.  I'm an evil mining pool operator in this example, say, so that won't take too long.  I make sure there are some multi-sig transactions in the block too.

I publish the block, spending the coin on the new chain, but the old chain rejects the block, since it contains multi-sig transactions.  Then I can spend the same coin again on the old chain.

Your beneficial cross-contamination idea only works if everyone's playing fair...

I think this is a realistic enough attack that it makes BIP 22 unworkable.

Pages: « 1 [2] 3 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!