Topic: BIP 16 / 17 in layman's terms - page 3. (Read 38982 times)

the coins can be spent after the first confirm. The 6 rule is to be sure they are deep enough so a double spend could not take them from you. You would pay the same fee with 1 or 6 confirms as the coins would have to age a little more if you wouldn't want to pay that.

I only carry a few BTC that are easily accessible from my phone.  The rest are on a locked down computer or paper storage.

Say I send 10 BTC to a shirt store to buy some shirts. It turns out I bought the wrong size shirt and so go to return it. They don't have the size I want and so I ask for a refund.

With cash, they can just give me cash back and I can go to another store and immediately buy something.

With bitcoin, if they credit my phone's wallet with the refund, I can't spend those coins at the store next door until I wait for 6 confirmations.  Depending on how many coins I have in my phone's wallet, this could be a problem.

Make sense?

EDIT: This has nothing to do with BIP 16/17

Lol wut

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

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

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.

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.

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.

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?

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).

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

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://bitcointalksearch.org/topic/m.733131

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

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.

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.

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

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 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.

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.

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.

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.

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.

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

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

For what platform?