BIP 16 / 17 in layman's terms

[Kluge]

I've noticed there's no voice for miners/users/enthusiasts who don't care one way or the other in this conversation. So.... Hello - I don't really care, and would opt-out of using this feature. I appreciate dumbing the conversation down so I can understand it, but I don't think I gained anything from reading it, except to learn Bitcoin users & devs have explosive, friendship-shattering arguments over whether to secure two pieces of wood together with glue, screws, or nails.

[1715238291]

1715238291

[1715238291]

1715238291

[grue]

It is apparent that Deepbit is now a community enemy.
That is, Deepbit wields too much power, handed to them by ignorant newbie miners who seem to love throwing away money, and uses that power against the democratic consensus of the developers and, perhaps, community as a whole.
There is no fucking reason that anybody should mine at Deepbit (variance is an excuse that anyone who has a working knowledge of statistics would ignore).  In fact, Deepbit should have been brought down months ago.  It has had close to 50% of the hash power of the network for far too long, and nobody listened.  This is what you get for not listening.
If Tycho believes that he has the right to block progress, then Deepbit must be forced from its position as the largest pool. 

I suggest that everyone pledge their hashing power, and when enough is collected in pledges, everyone should switch to p2pool at the same time (so that the transition is smooth).

edit: Everyone should copy my sig... we need Deepbit to fall.

i'm with you.

[ineededausername]

It is apparent that Deepbit is now a community enemy.
That is, Deepbit wields too much power, handed to them by ignorant newbie miners who seem to love throwing away money, and uses that power against the democratic consensus of the developers and, perhaps, community as a whole.
There is no fucking reason that anybody should mine at Deepbit (variance is an excuse that anyone who has a working knowledge of statistics would ignore).  In fact, Deepbit should have been brought down months ago.  It has had close to 50% of the hash power of the network for far too long, and nobody listened.  This is what you get for not listening.
If Tycho believes that he has the right to block progress, then Deepbit must be forced from its position as the largest pool. 

I suggest that everyone pledge their hashing power, and when enough is collected in pledges, everyone should switch to p2pool at the same time (so that the transition is smooth).

edit: Everyone should copy my sig... we need Deepbit to fall.

i'm with you.

Down with deepbit!
I will be PM spamming anyone with deepbit sigs I see and I urge everyone to do the same. 
Kluge: It's the principle of the thing that counts... one man should not have ultimate control over the direction of Bitcoin.  Also, BIP 16 and 17 look almost the same, and it's ridiculous that most devs have agreed on 16 but Tycho just refuses to implement it.

[adamstgBit]

I am a programmer, and my boss sometimes makes me re-work the code i write for "no reason" only because it looks and feels cleaner his way.... needless to say this can be a piss off, but in the end it really does produce clear strong code.

I hope the dev team isn't in too much conflict.

I dont understand the problem, but i will say this, i really dont care how long it takes as along as its "perfect" once its done. this isn't some web-app. Its the core for a brighter future  

keep up the good work!

Cheers

[Maged]

Would this make it easier to lose coins from human error? What happens if you lose your phone? Is it possible to allow very slow draining of a wallet with access to just one of the two private keys (e.g. max of 1 coin sent every 100 blocks)?

This way coins could be recovered even if one of the two factors is lost. It would also reduce user inconvenience for cases where security is not as essential. However, it would still be possible to steal very slowly.

Yes, this actually would be possible. To do what you asked, specifically, you would create 2-of-3 multisig transaction addresses where the third key is owned by a third party (likely web-based) service. When you lose access to one of your two private keys, you could use this service to recover your funds at whatever predetermined rate you chose. Such a service could require a login, or not, depending on the security you desire.

Alternatively, you could put the third private key in a safe and you would have immediate access to all of your funds should you lose a private key. Of course, this is no different than just storing a backup of both keys, but it's a little neater.

Residing in a country where you need two factor authentication for everything. I suspect that this modification (while very useful) could impose serious inconveniences on users if poorly implemented.

That's why it'll be encouraged for people to use 2-of-3 transactions instead of 2-of-2.

[cunicula]

Yes, this actually would be possible. To do what you asked, specifically, you would create 2-of-3 multisig transaction addresses where the third key is owned by a third party (likely web-based) service. When you lose access to one of your two private keys, you could use this service to recover your funds at whatever predetermined rate you chose. Such a service could require a login, or not, depending on the security you desire.

Why add in a web-based service since it is not necessary in theory? Does it have something to do with the code lacking awareness of the blockchain? Are the core code modifications necessary to remedy this too difficult?

In my view, there should be a plan where txns with time-dependent spending limits without help from a third-party service become possible at some point. Maybe this is too tough to achieve right now, but it seems like a cleaner, more convenient, and intuitive solution to me. Time-dependent spending limits have such prevalence in consumer banking that I think people will be uncomfortable without them.

Third party service providers can cause lots of problems. Many people are already quite uncomfortable with them. "Don't lose two things at once" strategies also make things quite complicated. People get worried by stuff that is complicated. Who wants to spend the mental energy to deal with multiple methods of authentication simultaneously? I'm not saying I don't see value-added in these proposals, it is just that they do not seem like permanent, first-best solutions to me.

Should we view these proposals as temporary fixes?

[Portnoy]

Down with deepbit!
I will be PM spamming anyone with deepbit sigs I see and I urge everyone to do the same. 

Ya, spamming always helps to bring people to your way of thinking... especially when you
do it in such a calm and non-arrogant manner as you have shown...  lol

one man should not have ultimate control over the direction of Bitcoin.

oh the irony... 


Death to all fanatics! 

[JusticeForYou]

This post is really appreciated. All one could say is that Gavin, the lead developer, needs help in cranking up pressure on a Pool Operator to switch.

So it boils down to:

Do you think Gavin is leading the community in the right direction?

Do you think a pool operator should wield so much power?

It would be assumed, that this community does not like entities having to much power.

So how will this community respond to Gavin's plea for help now that the issues are laid out and explained for the majority of users?


So lets crank up the GH/s and show everybody where the power is. Point those miners (temporally) to another pool, or solo mine for a bit. Lets push those rigs up to 13 TH/s or more.

Go, Go, Go, OP_TakeBack

VOTE, VOTE, VOTE.

[Inaba]

I think generally speaking, anyone mining on Deepbit is not going to be reading this thread or agreeing with it. 

[JusticeForYou]

I think generally speaking, anyone mining on Deepbit is not going to be reading this thread or agreeing with it. 

Yea, probably true. But nothing wrong with a little Pep Rally.

Information that Gavin provided could be read by almost anybody, (that can read), and decide for themselves now. Can you ask anything more. He obviously feels strongly for this issue. I put a little more faith in him and his decisions than others I guess.

[Maged]

Yes, this actually would be possible. To do what you asked, specifically, you would create 2-of-3 multisig transaction addresses where the third key is owned by a third party (likely web-based) service. When you lose access to one of your two private keys, you could use this service to recover your funds at whatever predetermined rate you chose. Such a service could require a login, or not, depending on the security you desire.

Why add in a web-based service since it is not necessary in theory? Does it have something to do with the code lacking awareness of the blockchain? Are the core code modifications necessary to remedy this too difficult?

In my view, there should be a plan where txns with time-dependent spending limits without help from a third-party service become possible at some point. Maybe this is too tough to achieve right now, but it seems like a cleaner, more convenient, and intuitive solution to me. Time-dependent spending limits have such prevalence in consumer banking that I think people will be uncomfortable without them.

Third party service providers can cause lots of problems. Many people are already quite uncomfortable with them. "Don't lose two things at once" strategies also make things quite complicated. People get worried by stuff that is complicated. Who wants to spend the mental energy? I'm not saying I don't see value-added in these proposals, it is just that they do not seem like first-best solutions for users.

Should we view these proposals as temporary fixes?

You're right that it's possible in theory. However, we're talking about quite a few major changes that would have to be done.
1) Transactions are not aware of the blockchain at all. For this, they'd at least need to be made aware of the timestamp of the block they were put in. All such blockchain-aware transactions would need to be locked for at least 100 blocks after they are included in the chain before being spendable again. Even that might not be enough, in theory, although we'd likely be able to get away with it in practice.
2) Transactions would need to be aware of the output of the transaction in which they are redeemed. This is needed to find out how much is being spent and put conditional checks on it.

Neither of these are easy tasks. They might not ever be safe, either.

[cunicula]

You're right that it's possible in theory. However, we're talking about quite a few major changes that would have to be done.
1) Transactions are not aware of the blockchain at all. For this, they'd at least need to be made aware of the timestamp of the block they were put in. All such blockchain-aware transactions would need to be locked for at least 100 blocks after they are included in the chain before being spendable again. Even that might not be enough, in theory, although we'd likely be able to get away with it in practice.
2) Transactions would need to be aware of the output of the transaction in which they are redeemed. This is needed to find out how much is being spent and put conditional checks on it.

Neither of these are easy tasks. They might not ever be safe, either.

I'm completely willing to believe that implementing an "aware" blockchain is not easy. I also understand that awareness would lead to attack methods which try to manipulate awareness. However, I'm confident that awareness would open the door for a number of useful features (spending limits, blockchain-based derivatives, and others). I also believe that potential attack problems could be worked out eventually. I don't want to get into a discussion about how the features would work here. Instead what I am asking for is a long-term position on awareness.

It is a long-term goal of the development team to make the bitcoin blockchain aware?

[ineededausername]

I am especially disturbed by the large miners still at deepbit. Miners with 15-20 Ghash/s could pave the way for smaller pool adoption, if they would only take the initiative. And the irony is, these miners have the most to gain by switching away from a pool with such high fees! It's really incredible that these people throw their money away for variance reduction. Over the long term, it's meaningless.

Anyway, it's time for the miners to wake up and protect their paycheck. If you keep the Bitcoin network in a state where too few people have too much control, don't cry when people lose interest in this "decentralized currency" and stop buying it from you.

Frankly, I'm not too disturbed by that.  Saddened, yes, but if you're enough of an idiot to mine at DeepBit with your GH then you deserve to lose money.  What I'm more concerned about is the effect that these idiots have on the security and the future of the Bitcoin network as a whole.

[Steve]

I'm glad that BIP-12 was abandoned, I'm not sure why Tycho would have preferred it.  OP_EVAL clearly complicates static analysis, which would complicate measures designed to combat script based DOS attacks.  It also doesn't really add anything of value (besides enabling p2sh transaction).  I can see why it's appealing to people though.  Everyone is used to scriptPubKey being the place where all the interesting script belongs and scriptSig being just a couple push operations.  OP_EVAL makes it "feel" like the interesting script is executing in the scriptPubKey.  This is a cargo cult.  I think people that have worked with the code in detail for a long time may be too close to the problem and need to step back a bit.

All transactions should have been p2sh type transactions from the very beginning.  There should never have been this concept of prepending scriptSig to scriptPubKey for execution.  ScriptPubKey should have always been just a hash value and validation should have always been to hash the script in scriptSig.  To get a bit beyond the confusing "scriptSig" and "scriptPubKey" terminology, outputs of a transaction should have always been just a hash (bitcoin address), not a script.  The inputs are where the script belongs…the script (which would typically include one or more public keys) must hash to the value specified in the corresponding output.  This allows the recipient to always specify the conditions for spending (they create the script, hash it, and that's the bitcoin address they give to the sender).  The script can be a simple, single signature, or something more interesting involving multiple signatures.

BIP-16 feels like BIP-12's little brother…still clinging to this flawed notion that all interesting script should be in the scriptPubKey.  And it requires special rules that implicitly execute code that was pushed on the stack in the scriptSig (if you read the script proposed in BIP-16, nowhere is there an opcode that says "execute that stuff on the stack" and yet, it must get executed…so you've created a special kind of script with special rules for what is executed).  BIP-17 is cleaner in my opinion…it doesn't try to push code onto the stack for the purpose of later execution, instead it just executes it as you normally would and code in the scriptPubKey verifies that the code that was just executed matches the hash (bitcoin address) in the scriptPubKey.

BIP-17 would seem to have a bit larger hole regarding the spendability of these transactions during the upgrade period (BIP-16 has a similar problem, but a bit less of a risk).  In neither case would I want to create one of these transactions with any significant amount of bitcoins before a super majority of miners support the new transactions (though BIP-17 is more risky).  Neither are really a problem once the super majority of miners are fully supporting the BIP.  I do fear that during the transition there will be an easy way for people to execute a double spend.  Both BIP-16 and BIP-17 make the following equally possible: you create a new style transaction that is mined by a miner supporting the new transactions (old nodes will accept those blocks).  You then deliberately create a transaction that spends out of this transaction, but put a bogus signature on it.  Old nodes/miners won't check the signature, but new nodes and miners will…your transaction will look perfectly ok to old nodes/miners…and you may even get lucky for a block or two if old miners mine your transaction (creating a chain split).  For this reason, I think it would be very advisable for everyone to upgrade their clients when either BIP-16 or BIP-17 get adopted.  The reason for wanting backward compatibility was to avoid requiring everyone to upgrade, but I think people that don't upgrade might be at risk even if a backward compatible approach is taken.

Overall, I think BIP-17 is the better proposal.

Note: one thing I think should be considered for standard BIP-17 style transactions is a test right after the code separator (so it's included in the hash) to ensure the proper number of arguments have been pushed onto the stack.  It seems that there is a hole where nodes could put additional things at the beginning of scriptSig without rendering a transaction invalid.  That seems bad.

[chrisrico]

The inputs are where the script belongs…the script (which would typically include one or more public keys) must hash to the value specified in the corresponding output.  This allows the recipient to always specify the conditions for spending (they create the script, hash it, and that's the bitcoin address they give to the sender).  The script can be a simple, single signature, or something more interesting involving multiple signatures.

I feel like I know a decent amount about the workings of Bitcoin - enough to comprehend this explanation but not come up with it - and I agree.

For this reason, I think it would be very advisable for everyone to upgrade their clients when either BIP-16 or BIP-17 get adopted.

I think the concern is that this is not likely to happen. I saw a figure somewhere that 70% of clients are running a version lower than 0.5.

What about a staged update like when the default fee changed 0.3.22/23?

[JusticeForYou]

If you really want people to adopt an updated client. As discussed in another thread, put some bit penny making capability back into it.

Then sell it. Hey, you might make 0.0000001 BTC every now and again.

The amount really doesn't matter. It is the idea that upgrading and running a node will make you something. The miners and Pools could care less about it, BUT the people with just -qt would.


There are currently about what? 30K nodes?  Hell, you could pay people to upgrade. Every one gets 0.01 BTC to upgrade. That would cost about: 300 BTC

You might even get donations towards such an endeavor.

[FreeMoney]

For this reason, I think it would be very advisable for everyone to upgrade their clients when either BIP-16 or BIP-17 get adopted.

I think the concern is that this is not likely to happen. I saw a figure somewhere that 70% of clients are running a version lower than 0.5.

What about a staged update like when the default fee changed 0.3.22/23?

I don't like to upgrade. I really appreciate the work that goes into new features and versions, but sometimes things go wrong and I want to stay months behind. I certainly see the value in the improvements being discussed, but what I need is working and my main priority is keeping it that way.

[istar]

If there is any risc of double spending could we make a deal with the exchanges.
Maybe they could email every customer telling them to upgrade their clients and shut down for 2 days (like in a weekend) during a risky period.

[Costia]

why are the bip17 addresses longer than BIP16?
from what i understand both need to contain only the hash of the {script+pubkeys}.

[kjj]

Right now, it looks like one person/pool (Tycho/deepbit) has enough hashing power to veto any change. I believe Tycho liked, and planned to support, the original OP_EVAL proposal, but doesn't like/support either BIP 16 or BIP 17 (he does like/support BIP 11, the multisignature-as-standard-transactions part of all this), so unless he changes his mind or there is a mass exodus from his pool short, multisignature bitcoin addresses will have to wait.

Gavin, do you know what he objects to in P2SH and/or CHV?