BIP 16 / 17 in layman's terms

[dayfall]

It's hard when Gavin makes it seem like I'm the only one who want BIP 17, so the other big pools take the chicken-and-egg position (we won't support it because nobody else does).

I just found out my pool was pro BIP 16.  I am not going to join Eligius because of the obvious reasons.  Is there another pro BIP 17 pool out there?

[1714071198]

1714071198

[1714071198]

1714071198

[1714071198]

1714071198

[1714071198]

1714071198

[1714071198]

1714071198

[1714071198]

1714071198

[Luke-Jr]

I just found out my pool was pro BIP 16.  I am not going to join Eligius because of the obvious reasons.

It's not obvious, but your choice is your own.

Is there another pro BIP 17 pool out there?

At least pool.itzod.ru, and you can use BIP 17-patched bitcoind with p2pool. I think EclipseMC might support BIP 17 as well, but I'm not sure if they have the patch deployed live yet.

Edit: It looks like pool.itzod.ru maybe failed to do it right, and is producing BIP 16 blocks? :/

Edit: Looks like those were made before applying the patch, and they hadn't yet found a block with it.

Would be nice if PiUK would make a BIP 17 pie chart and block breakdown...

[Rassah]

I just found out my pool was pro BIP 16.  I am not going to join Eligius because of the obvious reasons.

It's not obvious, but your choice is your own.

Maybe Eligius is anti-furry?

Are you able to make BIP16 and BIP17 voting bitcoind binaries?

[Luke-Jr]

Are you able to make BIP16 and BIP17 voting bitcoind binaries?

For what platform?

[Rassah]

Are you able to make BIP16 and BIP17 voting bitcoind binaries?

For what platform?

The one that people who only know enough about computers to be dangerous use: Windows.

[Luke-Jr]

Are you able to make BIP16 and BIP17 voting bitcoind binaries?

For what platform?

The one that people who only know enough about computers to be dangerous use: Windows.

Only BIP 17, and only if someone actually wants/needs it, then. :p

[giszmo]

LukeJr had an argument pro pool that I did not share and he's too religious about his point but I don't like Gavin's way of making propaganda against him talking about poisonous people neither. May the best solution win. Not the best propaganda. Screw a month delay.

[Technomage]

Talking like BIP 17 matters anymore is a complete waste of time. Gavin is the lead developer and he has locked BIP 16 as the solution. There have been no serious technical or security concerns over BIP 16 which would make it inferior to BIP 17. Comparing these two seems to be like comparing apples and oranges.

Reality is that one large pool and a bunch of small pools are already voting for BIP 16. Only a week from now another large pool will add its support to BIP 16, this is confirmed. I think there are some small pools that are adding their support soon as well.

The expectation is that Tycho will add Deepbit once the support for BIP 16 is high enough from the rest of the pools. We are currently looking at finally enabling P2SH during March. This is the most realistic scenario.

If you have doubts over BIP 16, the only thing to do right now is to help test it. If you trust Gavin or don't care, the best way you can help is by mining in the pools that support P2SH. Which is the majority of pools after BTC Guild finally starts voting.

Trying to vote for BIP 17 right now is a complete waste of time and effort and it will only make the transition to P2SH via BIP 16 less smooth. I suggest supporting BIP 16 and then helping to test it more. Finding serious issues in it is the only possible way that anything else will get implemented. The "burden of proof" in this case is with everyone else, not Gavin. He has a solid solution that works, either prove that it's bad or start supporting it. Preferably do the latter and soon.

[Luke-Jr]

Talking like BIP 17 matters anymore is a complete waste of time. Gavin is the lead developer and he has locked BIP 16 as the solution.

Gavin is the lead developer of one client. This is not about clients, this is about the protocol.

There have been no serious technical or security concerns over BIP 16 which would make it inferior to BIP 17. Comparing these two seems to be like comparing apples and oranges.

Actually, there has been one serious bug that resulted from the BIP 16 patch, and changes so many different things at once that it's quite possible it could create security or other bugs. BIP 17 has no serious technical or theoretical concerns, just "what if there's already a bug in the current code?".

Reality is that one large pool and a bunch of small pools are already voting for BIP 16. Only a week from now another large pool will add its support to BIP 16, this is confirmed. I think there are some small pools that are adding their support soon as well.

Reality is that one large pool and at least one small pool are already voting for BIP 17. Another large pool plans to add it as soon as possible, probably within the week.

If you have doubts over BIP 16, the only thing to do right now is to help test it.

The problem with BIP 16 itself is in the protocol changes. While it's possible to debug the client's implementation, that will never fix the protocol-level inconsistencies. On the other hand, there has been some talk of using transaction version 2 to implement BIP 16, which could result it in being made somewhat consistent. I hope something comes of this, and I plan to Withdraw BIP 17 if it's a sensible protocol change, despite the potential implementation risks.

Trying to vote for BIP 17 right now is a complete waste of time and effort and it will only make the transition to P2SH via BIP 16 less smooth. I suggest supporting BIP 16 and then helping to test it more. Finding serious issues in it is the only possible way that anything else will get implemented. The "burden of proof" in this case is with everyone else, not Gavin. He has a solid solution that works, either prove that it's bad or start supporting it. Preferably do the latter and soon.

This applies just as much with BIP 16/17 inverted, except that unlike BIP 16 (due to its complexity), BIP 17 is easily proven to be "probably good" by any C++ programmer.

[Technomage]

Reality is that one large pool and at least one small pool are already voting for BIP 17. Another large pool plans to add it as soon as possible, probably within the week.

What you and I qualify as large pools is probably different in this context. Of the three biggest pools one is voting 16, other one is soon voting 16 and the third, biggest one, is neutral and not voting anything until a voting concensus arises.

The problem with BIP 16 itself is in the protocol changes. While it's possible to debug the client's implementation, that will never fix the protocol-level inconsistencies. On the other hand, there has been some talk of using transaction version 2 to implement BIP 16, which could result it in being made somewhat consistent. I hope something comes of this, and I plan to Withdraw BIP 17 if it's a sensible protocol change, despite the potential implementation risks.

Even though I can't comment on the technical aspects of this debate, I like the sound of this a lot. Nothing would be better than a solution that all developers can at least find acceptable. I hope this modified BIP 16 works out so everyone is happy.

[dayfall]

Only BIP 17, and only if someone actually wants/needs it, then. :p

I doubt I can do the patch/compile.  So, I would like to have one.

[Math Man]

It's hard when Gavin makes it seem like I'm the only one who want BIP 17, so the other big pools take the chicken-and-egg position (we won't support it because nobody else does).

I just found out my pool was pro BIP 16.  I am not going to join Eligius because of the obvious reasons.  Is there another pro BIP 17 pool out there?

EclipseMC is offering a democratic vote for its miners and their support of the BIPs.  A miner may cast his vote by connecting to one of the three EclipseMC servers.

https://bitcointalk.org/index.php?topic=16385.msg733131#msg733131

[Luke-Jr]

Only BIP 17, and only if someone actually wants/needs it, then. :p

I doubt I can do the patch/compile.  So, I would like to have one.

Just wanted to follow up on this and mention I'm working on it... hopefully it'll be done later tonight.

[Luke-Jr]

Only BIP 17, and only if someone actually wants/needs it, then. :p

I doubt I can do the patch/compile.  So, I would like to have one.

Windows binaries for 0.5.2 with BIP 17 protocol support: http://luke.dashjr.org/programs/bitcoin/files/bip17/bip17_v0.5.2/

Be aware that (as with BIP 16 clients), these will begin strictly enforcing BIP 17 rules at a future date by default. If BIP 17 has not yet achieved a majority by this date, you will need to be prepared to change the date by editing your bitcoin.conf (or installing an update). For this binary, the default time is midnight UTC on Feb 22. It can be overridden by adding 'p2shtime=T' to your bitcoin.conf, where T is the UNIX time (number of seconds since midnight UTC Dec 31 1969).

[rupy]

I don't understand how a 2 phase commit will improve security when one of the phases will only practically be controlled by the attaker?

So say you go to the store and buy a snickers. Today you verify amount of BTC and destination address then send the money. The store sees the payment (one destination address per register) and lets you exit the store.

With these BIPS the only change is that the guy behind the register has to press an ACCEPT button right?

Am I understanding this correctly?

[Red Emerald]

I don't understand how a 2 phase commit will improve security when one of the phases will only practically be controlled by the attaker?

So say you go to the store and buy a snickers. Today you verify amount of BTC and destination address then send the money. The store sees the payment (one destination address per register) and lets you exit the store.

With these BIPS the only change is that the guy behind the register has to press an ACCEPT button right?

Am I understanding this correctly?

I don't think you are understanding this correctly.

Someone has to hit two accept buttons to spend those coins.  This keeps your cashiers from spending the funds without the boss' approval.

[FreeMoney]

I don't understand how a 2 phase commit will improve security when one of the phases will only practically be controlled by the attaker?

So say you go to the store and buy a snickers. Today you verify amount of BTC and destination address then send the money. The store sees the payment (one destination address per register) and lets you exit the store.

With these BIPS the only change is that the guy behind the register has to press an ACCEPT button right?

Am I understanding this correctly?

I don't think you are understanding this correctly.

Someone has to hit two accept buttons to spend those coins.  This keeps your cashiers from spending the funds without the boss' approval.

It seems rare that you'd need a cashier to have access, just pay give them watching only access. Multi-sig is for when multiple bosses need to sign off and other cases like that.

[kjj]

I don't understand how a 2 phase commit will improve security when one of the phases will only practically be controlled by the attaker?

So say you go to the store and buy a snickers. Today you verify amount of BTC and destination address then send the money. The store sees the payment (one destination address per register) and lets you exit the store.

With these BIPS the only change is that the guy behind the register has to press an ACCEPT button right?

Am I understanding this correctly?

I don't think you are understanding this correctly.

Someone has to hit two accept buttons to spend those coins.  This keeps your cashiers from spending the funds without the boss' approval.

It seems rare that you'd need a cashier to have access, just pay give them watching only access. Multi-sig is for when multiple bosses need to sign off and other cases like that.

what about for refunds? i wouldn't say that's rare.

Cashiers would have access to a small wallet for refunds, with the ability to ask a manager for larger refunds.  A refund doesn't need to be the return of the same coins, just the same amount.

[Red Emerald]

I don't understand how a 2 phase commit will improve security when one of the phases will only practically be controlled by the attaker?

So say you go to the store and buy a snickers. Today you verify amount of BTC and destination address then send the money. The store sees the payment (one destination address per register) and lets you exit the store.

With these BIPS the only change is that the guy behind the register has to press an ACCEPT button right?

Am I understanding this correctly?

I don't think you are understanding this correctly.

Someone has to hit two accept buttons to spend those coins.  This keeps your cashiers from spending the funds without the boss' approval.

It seems rare that you'd need a cashier to have access, just pay give them watching only access. Multi-sig is for when multiple bosses need to sign off and other cases like that.

what about for refunds? i wouldn't say that's rare.

Cashiers would have access to a small wallet for refunds, with the ability to ask a manager for larger refunds.  A refund doesn't need to be the return of the same coins, just the same amount.

Waiting 6 confirmations to get refunded might suck.  Especially if its the fault of the cashier.

[Explodicle]

Why wait 6 confirmations for POS transactions? You should just accept unconfirmed POS refunds. 6 confirmations is for a king's ransom.