Bitcoin Forum
December 05, 2016, 04:54:46 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Questions about BIP 16 / 17 in layman's terms  (Read 3477 times)
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
January 26, 2012, 09:45:00 PM
 #1

What are the substantive issues? Here are how I see them:

1. It's prudent to avoid executing data from the stack. Why? Because you have a scripts that manipulate data on the stack. Obviously the system is designed so that scripts can't manipulate the data that is going to be executed. But if there is a bug, you have all the pieces in place for an exploit. The script doesn't have opcodes to manipulate off-stack data, so Luke's implementation seems safer.

2. Supporters of BIP 16 claim that it allows 5-10 times more headroom before block size limits are reached. Supporters of BIP 17 claim that it puts fewer bytes into the block. [Edit: Gavin has explained the headroom issue, but BIP 17 still seems more scalable to me because it puts fewer bytes into the block chain.]

3. It's clear that both BIP 16 and BIP 17 transactions can be spent by others if those transactions are broadcast before 50% of the mining power (plus a safety margin) supports them. It's also clear that the BIP 17 transactions are easier to spend in this situation. However I think this is a non-issue because (a) mining power will quickly rise above 50% once consensus is reached, and (b) who is going to broadcast these newfangled transactions before the mining power is there to support them?

3. Gavin needs to say whether it's commercially relevant to his current work project. [Edit: Gavin has made it absolutely clear that BIP 16 is not driven by any commercial pressure, so as far as I'm concerned this is a non-issue and the rumors can be ignored.]

4. BIP 17 "feels" like a more general approach to the problem, and BIP 16 "feels" a bit more like a special-cased design change.

5. BIP 17 "feels" like a less-developed solution, and BIP 16 "feels" like one that has already had a little more contemplation.

Of these 5 issues, I think only (1) and (2) are of any real consequence.
1480956886
Hero Member
*
Offline Offline

Posts: 1480956886

View Profile Personal Message (Offline)

Ignore
1480956886
Reply with quote  #2

1480956886
Report to moderator
1480956886
Hero Member
*
Offline Offline

Posts: 1480956886

View Profile Personal Message (Offline)

Ignore
1480956886
Reply with quote  #2

1480956886
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480956886
Hero Member
*
Offline Offline

Posts: 1480956886

View Profile Personal Message (Offline)

Ignore
1480956886
Reply with quote  #2

1480956886
Report to moderator
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
January 26, 2012, 10:19:01 PM
 #2

1. It's prudent to avoid executing data from the stack. Why? Because you have a scripts that manipulate data on the stack. Obviously the system is designed so that scripts can't manipulate the data that is going to be executed. But if there is a bug, you have all the pieces in place for an exploit. The script doesn't have opcodes to manipulate off-stack data, so Luke's implementation seems safer.

Did you read BIP 16?

Quote
Validation fails if there are any operations other than "push data" operations in the scriptSig.

So there is no manipulation allowed AT ALL.

Quote
2. Supporters of BIP 16 claim that it allows 5-10 times more headroom before block size limits are reached. Supporters of BIP 17 claim that it puts fewer bytes into the block. Can someone please make a clear statement about what these proposals actually mean for scalability?

A maximum of 1,000 "naked" OP_CHECKMULTISIG operations are allowed in the scriptSigs and scriptPubKeys of transactions in any given block.

We had a block earlier this month with 1,8000 scriptSigs, so I think we are uncomfortably close to that limit.

BIP 16 "hides" the CHECKMULTISIGS in the serialized script, so more of them are allowed.

Quote
3. It's clear that both BIP 16 and BIP 17 transactions can be spent by others if those transactions are broadcast before 50% of the mining power (plus a safety margin) supports them. It's also clear that the BIP 17 transactions are easier to spend in this situation. However I think this is a non-issue because (a) mining power will quickly rise above 50% once consensus is reached, and (b) who is going to broadcast these newfangled transactions before the mining power is there to support them?

At the very least BIP 17 is harder to test-- Luke had to test on the main network because I was naughty and wrote and ran a BIP-17-transaction-stealing bot (sorry, I couldn't resist).

Quote
3. I have a vague feeling of undue haste. Gavin has already said that his motivation is the security of people's transactions, and I don't doubt it. But is that the whole motivation? Gavin needs to say whether it's commercially relevant to his current work project whether BIP 16 or BIP 17 is chosen (or how quickly the new functionality is firmed up). It's no big deal if Gavin has a commercial interest. In that case, he should just step aside from administering the oversight of this particular decision.

I have zero commercial interest; I am not being paid by anybody for anything right now.

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

Activity: 868



View Profile WWW
January 26, 2012, 10:31:49 PM
 #3

3. I have a vague feeling of undue haste.
You shouldn't, people have been thinking about these issues and coming up with solutions since at least August of 2011.

The principal concern that Gavin has is related to upgrade and executing well tread code paths in the implementation.  Despite having done much work on the core client, I did refactor the entire codebase once…so I can appreciate the desire to make only conservative changes.  If you've ever worked on a large body of code that isn't well covered by unit tests, you know what I mean.  As much as I think BIP-17 is a bit cleaner, I think I have to say BIP-16 is the more conservative approach.  And, it won't impair the ability to adopt a cleaner solution or even an entirely different scripting engine in the future.

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

Activity: 826


View Profile
January 27, 2012, 10:43:00 AM
 #4

1. It's prudent to avoid executing data from the stack...

Quote from: BIP 16
Validation fails if there are any operations other than "push data" operations in the scriptSig.

So there is no manipulation allowed AT ALL.

Well, exactly. The design of BIP 16 is safe. A bug-free implementation of BIP 16 is also safe. But in the presence of a bug, an additional facet of the system is exposed to a possible exploit. So BIP 17 has an advantage here.

A maximum of 1,000 "naked" OP_CHECKMULTISIG operations are allowed in the scriptSigs and scriptPubKeys of transactions in any given block ... BIP 16 "hides" the CHECKMULTISIGS in the serialized script, so more of them are allowed.

Thanks for this explanation. The limit of 1000 can, of course, be eased in the future. If BIP 17 puts fewer bytes into the block chain, the potential for easing any future limits (not just this one) is greater, so BIP 17 surely has a slight advantage here.

Luke had to test on the main network because I was naughty and wrote and ran a BIP-17-transaction-stealing bot (sorry, I couldn't resist).

Trying to break things can help to make them more robust Smiley

Gavin needs to say whether it's commercially relevant to his current work project whether BIP 16 or BIP 17 is chosen

I have zero commercial interest; I am not being paid by anybody for anything right now.

OK thanks for that unambiguous statement, which neutralises the rumors and makes this a total non-issue. I've edited my earlier post to reflect this.

ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
January 27, 2012, 11:02:05 AM
 #5

... people have been thinking about these issues and coming up with solutions since at least August of 2011 ...
That's not actually a long time for a design decision with long-term consequences. Because of not rushing into this in 2011, it has been possible to improve on some of the earlier designs.

... If you've ever worked on a large body of code that isn't well covered by unit tests, you know what I mean.  As much as I think BIP-17 is a bit cleaner, I think I have to say BIP-16 is the more conservative approach.

As it happens, I do maintain a large body of PHP code that is not well covered by unit tests. As a result, I almost always make only the most conservative changes.

But when something (a) is important, (b) has long-term consequences, and (c) has the potential for a cleaner but less-conservative change, I do my best to find the time to make the change that is cleaner in the long-term. When I can't manage that, I always feel a little bit ashamed of my code.

Although I contribute to the Bitcoin community in many ways, I've never contributed a line of code, nor am I currently mining, so I haven't earned any right to have a say in this. All I'm hoping to do is to clarify some of the issues so that everyone can feel comfortable with the decisions made by those who are entitled to make the decision. No-one should be left with the impression that any issues were overlooked or misunderstood by anyone making the decision, so I appreciate the clarifications here and elsewhere.
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
January 27, 2012, 09:32:26 PM
 #6

At the very least BIP 17 is harder to test-- Luke had to test on the main network because I was naughty and wrote and ran a BIP-17-transaction-stealing bot (sorry, I couldn't resist).
BIP 17 can be easily tested by setting the activation time to 0 and running on testnet. Such clients will reject all non-compliant blocks, and should be sufficiently secure. The only problem your bot made was looking at them in Block Explorer. Wink

The principal concern that Gavin has is related to upgrade and executing well tread code paths in the implementation.
That's half the problem. The BIPs are about protocol changes, and the specifics of any one particular implementation should be ignored. Also, the BIP 17 implementation in bitcoind changes significantly less code, and doesn't really execute any new code paths (all the "questionable" code paths mentioned are already enabled).

Steve
Hero Member
*****
Offline Offline

Activity: 868



View Profile WWW
January 27, 2012, 09:45:08 PM
 #7

At the very least BIP 17 is harder to test-- Luke had to test on the main network because I was naughty and wrote and ran a BIP-17-transaction-stealing bot (sorry, I couldn't resist).
BIP 17 can be easily tested by setting the activation time to 0 and running on testnet. Such clients will reject all non-compliant blocks, and should be sufficiently secure. The only problem your bot made was looking at them in Block Explorer. Wink

The principal concern that Gavin has is related to upgrade and executing well tread code paths in the implementation.
and the specifics of any one particular implementation should be ignored.
I would agree with this were it not for the fact that 99% of all clients are running this script engine.  If there were say 10 different script engines in use, the impact of one of them having an exploitable bug would be much less severe.  In such a scenario, if a particular engine was flawed and allowed an invalid transaction into a block, you would have a chain split with the majority of the network rejecting that block.  It should be spotted quickly (people could run nodes that use multiple script engines to detect it right away) and the people using that script engine could be alerted.  They could switch out their script engine, or wait on a patch (the vast majority of transaction would still be valid on both forks of the chain and the affected people would only be on the bad fork for a short time until the rest of the network overtakes it).

(gasteve on IRC) Does your website accept cash? https://bitpay.com
Pages: [1]
  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!