Bitcoin Forum
December 04, 2016, 08:19:57 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 [4] 5 6 »  All
  Print  
Author Topic: BIP 17  (Read 8101 times)
Costia
Newbie
*
Offline Offline

Activity: 28



View Profile
January 26, 2012, 06:46:43 PM
 #61

you dont need computing power, you just send a competing transaction, and wichever gets first into a block will be accepted

BTW, why is the address of BIP17 longer than BIP16?
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480839597
Hero Member
*
Offline Offline

Posts: 1480839597

View Profile Personal Message (Offline)

Ignore
1480839597
Reply with quote  #2

1480839597
Report to moderator
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
January 26, 2012, 06:53:49 PM
 #62

BTW, why is the address of BIP17 longer than BIP16?
BIP17 and BIP16 both use BIP13 addresses...

Costia
Newbie
*
Offline Offline

Activity: 28



View Profile
January 26, 2012, 07:31:37 PM
 #63

is there already an implementation of both BIPs?
jojkaart
Member
**
Offline Offline

Activity: 97


View Profile
January 26, 2012, 07:39:28 PM
 #64

...And even BIP16, which also evaluates code you push on the stack, seems wrong to me (and would make the implementation more complex and static analysis more difficult).

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

Let me try again for why I think it is a bad idea to put anything besides "push data" in the scriptSig:

Bitcoin version 0.1 evaluated transactions by doing this:

Code:
Evaluate(scriptSig + OP_CODESEPARATOR + scriptPubKey)

That turned out to be a bad idea, because one person controls what is in the scriptPubKey and another the scriptSig.

Part of the fix was to change evaluation to:

Code:
stack = Evaluate(scriptSig)
Evaluate(scriptPubKey, stack)

That gives a potential attacker much less ability to leverage some bug or flaw in the scripting system.

BIP 17 could gain the same robustness by the following (in python-like pseudocode):
Code:
MetaEvaluate(scriptSig + OP_CODESEPARATOR + scriptPubKey)

Where MetaEvaluate is a function that:
Code:
def MetaEvaluate(code):
    pieces = code_split(code, OP_CODESEPARATOR)
    stack = emptyStack
    foreach piece in pieces:
        stack = Evaluate(piece,stack)

I'm not going to write pseudocode for code_split but the first argument is the code to be split and the second is the instruction by which to separate it. I'm not sure if it makes sense to be able to split at any instruction but OP_CODESEPARATOR though. code_split does need to understand not to split in the middle of data though, so pure split won't work.
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
January 26, 2012, 08:14:02 PM
 #65

is there already an implementation of both BIPs?
Yes, BIP 16 is in mainline git master, and BIP 17 has implementations for 0.3.19 onward.

BIP 17 could gain the same robustness by the following (in python-like pseudocode):
Code:
MetaEvaluate(scriptSig + OP_CODESEPARATOR + scriptPubKey)

Where MetaEvaluate is a function that:
Code:
def MetaEvaluate(code):
    pieces = code_split(code, OP_CODESEPARATOR)
    stack = emptyStack
    foreach piece in pieces:
        stack = Evaluate(piece,stack)

I'm not going to write pseudocode for code_split but the first argument is the code to be split and the second is the instruction by which to separate it. I'm not sure if it makes sense to be able to split at any instruction but OP_CODESEPARATOR though. code_split does need to understand not to split in the middle of data though, so pure split won't work.
Interesting, but it seems more likely to break something subtle to me, at least in regard to backward compatibility. But perhaps this option should be explored more if we have the time.

Maged
Legendary
*
Offline Offline

Activity: 1260


View Profile
January 26, 2012, 09:04:20 PM
 #66

But i do not feel that bip17 is mature enough since it introduces new security risks.
So i think something like bip17 should be implemented, but in a way that cannot be exploited/misenterpreted by older clients even if BIPXX has less than 50% support.
BIP 17 does not introduce any new security risks that aren't also risks with BIP 16.
it does. if you send a new transaction before 50% of the hash power is updated it will be redeemable by anyone
with bip16, you will at least need to know the script - its not much, but its not nothing either.
And to redeem it, you have to make the script known even before your redemption gets confirmed. So any rogue miner/relayer can easily swipe it the moment you try to spend.
On the contrary, you don't have to make the script known publicly to redeem it. You can mine it yourself, or get someone that you trust completely to mine it for you. Once it's in a block, the only danger is that the block could be orphaned, and since the script is now publicly released, other people could try redeeming it.

However, that is significantly better than BIP 17 where anyone can try redeeming it the second the BIP 17 transaction appears on the network.

Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
January 26, 2012, 09:35:19 PM
 #67

However, that is significantly better than BIP 17 where anyone can try redeeming it the second the BIP 17 transaction appears on the network.
Not considering both BIPs require a supermajority hashpower of support to become active. Wink

theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
January 26, 2012, 11:14:09 PM
 #68

At the moment I slightly prefer BIP 16 over 17. BIP 16 seems a little more security-conservative because the scripting system isn't being modified and non-P2SH scripts will not be touched at all. There's no chance that anyone will actually want to use "OP_HASH160 [20-byte-hash-value] OP_EQUAL" as their entire scriptPubKey unless they're using P2SH, so I don't believe that BIP 16 undermines Script.

I find P2SH's use of special-case-scripts to be inelegant, though Script is already inconsistent and inelegant, so I don't care that much. Hopefully when the max block size is increased, Script will be totally revamped to fix all of the imperfections.

I'm amazed at how much argument there is over this tiny issue. BIP 16 and 17 have few real differences (and these differences are very technical), but it seems like everyone on this forum has some strongly-held opinion about it.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416


View Profile
January 27, 2012, 12:29:58 AM
 #69

I'm amazed at how much argument there is over this tiny issue.

The differences seem small and I'm confident that technical issues are not what is causing the controversy.
Of course, I would have liked OP_EVAL to succeed as I thought it led Bitcoin in a direction I thought would be healthy in the long run.

The current arguments bode ill for getting a vague consensus for more profound changes probably required in future. Imagine Satoshi trying to deploy IsStandard() if he had to deal with the current situation.

Part of the problem is that the pool operators are vital to the success of upgrades and they only really care about mining and the exchange rate!

ByteCoin
finway
Hero Member
*****
Offline Offline

Activity: 714


View Profile
January 27, 2012, 12:43:01 AM
 #70

http://blockchain.info/p2sh

I'm disapointed.

Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
January 27, 2012, 01:01:31 AM
 #71

Me too. Too many votes for BIP16

Inaba
Legendary
*
Offline Offline

Activity: 1260



View Profile WWW
January 27, 2012, 01:26:43 AM
 #72

The current arguments bode ill for getting a vague consensus for more profound changes probably required in future. Imagine Satoshi trying to deploy IsStandard() if he had to deal with the current situation.

Part of the problem is that the pool operators are vital to the success of upgrades and they only really care about mining and the exchange rate!

I don't think it bodes ill at all.  I think, in the future, if something like this is handled properly as a roll out, things will go very well.  This entire thing was botched from the beginning as far as the rollout goes and then quickly devolved into this mess. 

I also highly disagree that the pool operators only care about mining and the exchange rate.  Speaking personally, I care about what's best for the miners and the stability of the pool.  For my part, my objection over this is the fact that the timeframe was so short to make changes/deployment, after evaluating what, exactly, is being proposed.

If you're searching these lines for a point, you've probably missed it.  There was never anything there in the first place.
finway
Hero Member
*****
Offline Offline

Activity: 714


View Profile
January 27, 2012, 02:27:24 AM
 #73


Oh, slush just started to support P2SH, it'll be more.

But surely P2SH will be delayed, again, because of you. Nice Work, Luke.

Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
January 27, 2012, 02:58:28 AM
 #74

I don't think it bodes ill at all.  I think, in the future, if something like this is handled properly as a roll out, things will go very well.  This entire thing was botched from the beginning as far as the rollout goes and then quickly devolved into this mess. 
We all learn from our mistakes.

Would you be willing to write an "informational BIP" describing how to do a rollout right in the future?

I'm terrible at that kind of "first we'll need to get buy-in from groups X, Y, and Z by doing A, B, and C, then each of those groups will elect representatives who will have three days to agree to a schedule, which will be announced blah blah blah blah"

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

Activity: 1260



View Profile WWW
January 27, 2012, 03:31:59 AM
 #75

I'll have to review the BIP format and requirements, but I can probably put something together.  It's based on the Python development RFC format or something, yeah?

If you're searching these lines for a point, you've probably missed it.  There was never anything there in the first place.
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
January 27, 2012, 03:38:57 AM
 #76

I'll have to review the BIP format and requirements, but I can probably put something together.  It's based on the Python development RFC format or something, yeah?
Yes, BIPs are based on PIPs and BEPs (for Python and BitTorrent).  See BIP 0001 for the process.

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

Activity: 924


Firstbits: 1pirata


View Profile WWW
January 27, 2012, 03:42:07 AM
 #77

I'll have to review the BIP format and requirements, but I can probably put something together.  It's based on the Python development RFC format or something, yeah?
Yes, BIPs are based on PIPs and BEPs (for Python and BitTorrent).  See BIP 0001 for the process.

i think it would had a better success as BRFC (Bitcoin Request For Comments)

BTCitcoin: An Idea Worth Saving - Q&A with bitcoins on rugatu.com - Check my rep
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
January 27, 2012, 04:15:55 AM
 #78

But surely P2SH will be delayed, again, because of you. Nice Work, Luke.
The only unnecessary delay at this point is from people trying to push BIP 16 through when we have a sane alternative. If everyone was focussed on BIP 17, we'd be there in no time. Wink

ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416


View Profile
January 27, 2012, 04:29:40 AM
 #79

This entire thing was botched from the beginning as far as the rollout goes and then quickly devolved into this mess. 

My assessment is that the current state of disagreement is a rather freakish conspiracy of circumstances and would have been impossible to predict and/or avoid. Please outline how it was botched. Here's a little history as I see it:

In the beginning there was casascius' proposal which virtually nobody bothered to understand. This rapidly transformed into a proposal to "reinterpret" OP_CHECKSIG with some code to recognize legacy cases to ensure back compatibility. This was rejected because the special case interpretation was seen as a hack and destroyed the "purity" of the scripting language - rather ironic in light of the current hacky solutions. Gavin then gathered fairly broad support around my OP_EVAL proposal and everything was going smoothly for a few months until roconnor finds some bugs and some low-to-zero-practical-impact disadvantages. Gavin lobotomizes the scheme in an ugly fashion to allay these concerns, probably assuming that the adoption of the more cautious scheme will be uncontroversial. With reasonable justification but with little regard for propriety or the long-term consequences, Luke-Jr objects to Gavin's scheme's violation of the script and uses his considerable technical and social capital to engineer the scheme's failure. This brings us up-to-date.

To apportion the blame fairly, it should be mentioned that roconnor was threatening to spread FUD about the "dangers" of OP_EVAL if his demands were not met, regardless of the incidental damage to Bitcoin.

ByteCoin
Red Emerald
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW
January 27, 2012, 05:00:09 AM
 #80

ByteCoin

So which BIP are you voting for?  Wink

Pages: « 1 2 3 [4] 5 6 »  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!