Bitcoin Forum

So you might have rumblings about changes to the network:  OP_EVAL and BIP 16 and BIP 17 and multisig and P2SH, and you wonder what the heck is going on.

Here's my view; I'll try not to get too technical.

First, the feature:

I want more secure wallets. There's unanimous agreement among developers that the easiest, fastest way to get there is with "multi-signature transactions" -- bitcoins that require approval from more than one person or device to spend.

For example, a future version of Bitcoin-Qt might know how to talk to an app running on your mobile phone. When you send bitcoins, it would provide one signature, but it would have to ask your phone for approval and the other signature.  That way even if your computer gets compromised by malware your bitcoins absolutely positively cannot be stolen, since the best the malware could do would be to ask your phone to approve the "Send the bad guys bitcoins" transaction.

The bitcoin network protocol already mostly support multi-signature transactions, although they're considered "non-standard" right now.  Part of what is going in is making them standard.  That's not controversial.

What is causing all the discussion is how to support sending coins into one of these new, spiffy, secure wallets.  There is rough consensus that the best way to do that right now is with a new type of bitcoin address; I say "rough consensus" because in a perfect world some people think that there wouldn't be bitcoin addresses visible to users at all.  And I say "right now" because we don't live in a perfect world, and there are no proposals for how, exactly, to replace bitcoin addresses with something better.

Part of the controversy is whether really long bitcoin addresses would work-- would it be OK if the new bitcoin addresses were really long and looked something like this:
  57HrrfEw6ZgRS58dygiHhfN7vVhaPaBE7HrrfEw6ZgRS58dygiHhfN7vVhaPaBiTE7vVhaPaBE7Hr
(or possibly even longer)

I've argued no: past 70 or so characters it becomes a lot harder to copy and paste, a lot harder to scan an address with your eyes to see if you're paying who you think you're paying, harder to create a readable QR code, harder to upgrade website or database code that deals with bitcoin addresses, etc. There is rough consensus that very-long addresses are not workable.

So: there are three proposals on how to support short multisignature addresses-- BIP 12, 16, and 17.

I withdrew BIP 12 (also known as "OP_EVAL") because I try to be extremely conservative when it comes to changes to core Bitcoin, and I think BIP 16 is a safer way to go.

Luke Dashjr liked OP_EVAL, really doesn't like BIP 16, and came up with BIP 17, which solves the same problem in a different way. I still like BIP 16 best, because I think it is the most conservative, safest solution. The number of people who understand the guts of Bitcoin well enough to have an informed opinion about which is better is pretty darn small, but I think the controversy is really about how conservative we aught to be.

All of the BIP 12/16/17 stuff is mostly engineers arguing over whether it is better to use a nail, a screw, or glue to put two pieces of wood together. Any of the solutions would work, and ordinary users wouldn't notice any difference; you'll still (eventually) get spiffy, more secure wallets.

(don't take the analogy too far, in this case using a nail AND a screw AND some glue to be extra safe isn't an option).

How dangerous is all this?  Is the bitcoin network in danger of falling apart one of these BIPs is adopted?

The worst-case scenario for all of this stuff (including the non-controversial support of multisignature transactions as "standard") is that some bug will slip by, and an attacker will figure out a way of getting all the nodes running the new software to crash or misbehave. I'm working hard to prevent that from happening-- I've been writing "unit tests" and "fuzzing tools" and have been getting other developers to look really hard at the code.  I strongly believe that the new feature is worth the (small) risk, and that even in the worst-case scenario the consequences are not catastrophic (we'd just fix the bug and come out with a new release; everybody still running old code would continue to confirm transactions and create blocks while the early adopters were busy downloading and installing the fixed software).

The bitcoin network is NOT in danger of falling apart if any of these are adopted; they are all backwards-compatible, so old software will continue to work exactly as before.

Some footnotes (and sorry for making this so long):

I concentrated on multisignature transactions for secure wallets, but they're useful for several other things, including escrow transactions and "emergency offline backup keys" for wallet backups.

I've set an arbitrary deadline of February 1'st for deciding whether or not to "turn on" the new short-multisignature-bitcoin-address-support feature, mostly because deadlines are the only way I know to actually get people to pay attention. If you read the BIPs, those deadlines are designed to be flexible, so if there is NOT a majority of support or "we" think that not enough time has gone by or enough testing has been done they can (and will) be slipped.

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,

Can you address what lasting changes this will have to the blockchain, both good and bad that are irreversible once BIP 16 or 17 is accepted and activated?

Has it really come to this... bitcoin community having to beg one person to accept changes. I am in shock!

Indeed, we are coin whores parted out to the highest bidder. we need more small pools, and more adoption by the masses.

does it mean that with a 51% attack that reverses support for bip17 all multisig transactions will be redeemable by the attacker?

I'm with bitminter, and you'll hear no complaints from me about how Doc runs things.

I think the number one most shocking thing about the whole issue is the power Tycho holds over this. It's ridiculous. If the potential of a 51% attack wasn't enough, but now this. I hope Deepbit users finally start to consider using a smaller pool or even p2pool.

I don't really understand the differences that these different solutions have so I can't really comment on this from a technical standpoint. One thing I can say is that I strongly agree with Gavin that this is a much needed feature that would make Bitcoin much better than it is now.

However it has been proven now that this is also the most difficult change Bitcoin has faced so far, it should be handled carefully. I think it's important that we don't just forget about this now and move on, even though it's very tiresome to developers such as Gavin, I believe this issue needs to be settled even if it takes another month.

Finally, I have to say that I appreciate the work Gavin is doing and the hardship he is enduring because of the difficulties in trying to get this feature into Bitcoin. Keep it up, you're doing very important work. The same goes to the other developers as well but I can see this being especially hard for Gavin because he is the main developer.

There's no need for a rush decision. In time, and with further calm-headed discussion, support may gravitate towards BIP 16 or BIP 17, or perhaps a BIPxx will emerge that is superior to both.

It doesn't matter if this takes another six months to get this right.

I have one of my rigs on p2pool, I have no idea even how to vote (assuming I get a block). Where is the voting for dummies thread?

@ Gavin

Call me dumb, but I absolutely do not understand how you are supposed to create a whole address out of partial sigs?!? Wouldn't it be necessary for all sigs to come together at one point to create a single address hash to which you can then send the coins?
And if so, why don't you just take one private key, divide it into two or three or more parts (like this: 5JMhGPWc3pkdgPd9jqVZkRtEp3QB3Ze8ihv62TmmvzABmkNzBHw ) and then give each part to different people or devices.


Can you please explain in more detail?

I think the code is saying "in order for this transaction to be spent, it must be signed by private key (X and Y) or Z". This allows more flexibility, because Z can be printed out and kept physically safe, in case X or Y (kept in separate locations) is lost. You can also say something like "...it must be signed by at least 51% of A through Z".

Thanks! Very helpful for us customers. ;)

Bitcoin addresses today correspond to one public key in your wallet.

Signatures enter the picture when you spend the bitcoins sent to an address; your private key is used to generate the right digital signature, proving that you actually have that key.

BIP 16/17 will enable bitcoin addresses that are associated with more than one public key. Your wallet will know both public keys, but will only know ONE of the private keys needed to spend the bitcoins (your phone or a "wallet protection service" will keep the other private key safe).

So when sending coins, your wallet will provide one signature for the private key that it knows, the other required signature must come from whatever device is holding the other private key.

The public keys aren't just strung together in a row, but are combined using a secure hashing algorithm (the same algorithm that is used to associate public keys with the bitcoin addresses we're all using today).

I would advocate for whichever option that makes things difficult now, but easier in the future to work with. For too long we, as a society, have implemented policies and technologies based on how convenient they are, as opposed to those which are better for the long term health and sustainability of our species. Can you tell us which would be better for the long term development of bitcoin, its continued function and the specific challenges we would face in the short term? I appreciate the fastener analogy, but that still is fairly vague.

Seeing Gavins forum signature makes me want to cry... Bitcoin, nooooo! You used to be strong and follow noone's rules, now you're like a little slave begging your master for a bone.

It's time for a digital riot against our overlord. Who's up for funding an attack on deepbit?

There is a time and place for this, and the bitcointalk.org forums are not it. Try l33thackers.com or blackhat.com for this kind of talk.

After a bit of reading it appears like p2sh allows the payer to place conditions upon which the payee can receive the payment. The question that now remains is what are the possible conditions. Can I do something like this:

"Here are your coins, but before you can receive them in your wallet, you will have to solve this: (5+5)
Or you will have to send me a pic of your... um... cat! Yeah that's it.." ?
.

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 can understand the resentment for deepbit, but we as a community let this happen. We the sheeple have given our computing power not at the point of a sword, but at the promise of regular payouts.

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.

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.

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.

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.

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

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.

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

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?

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


oh the irony... 


Death to all fanatics! 

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.

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.

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?

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.

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.

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.


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?

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.

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.

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.

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

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

Have you tested the 0.5 (or whatever) migration to qt? It's a pretty slick interface.

To me this is not about which solution we use or when we apply it, we can keep going for a couple of months more if that is required. Multisig is an important feature but there is now something even more important going on which is the centralization of the mining network. This issue has proven that we actually have a much bigger problem right now.

This problem will never entirely go away but what we can do is make it better, a lot better. We can start by reducing the power of Deepbit and other large pools. Join me in the biggest boycott Bitcoin has ever seen. This can be done and this HAS TO BE DONE.

Read more here: https://bitcointalk.org/index.php?topic=61219.0

I can't say I've entirely understood how BIP16 or BIP17 work (but I'm not completely ignorant of them); however:

• BIP16 feels "hackish"; that is not to say BIP17 is therefore "the one", and it might be that an as yet unwritten BIP18 is the answer.  That being said, there is an awful lot of "hackish" already in the scripting part of bitcoin... OP_CODESEPARATOR makes me uncomfortable anyway.
• The inertia needed to be overcome for a change, suggests that changes should be made very judiciously.
• Deadlines are for closed source software.  The most uncomfortable part about this for me was the sudden announcement of a deadline.

In general: I think if there is controversy, then the answer is not to rush it is to delay.  But  then again... I'm not the project lead am I?  :)

I really didn't expected to see such a lie from Gavin. Other pools have at least 50% of hashing power, just Slush and BTCguild are 27% combined. How can I outhash all the network with my current 32% ? (according to blockchaininfo's pie chart)
Of course I can't veto any change. I respect Gavin for all his hard work for Bitcoin's future, but this post was really SHOCKING for me. Is it really him ?
May be he sees that at this moment only 2% of the network supports his proposal and this is the way he wants to push it - by forcing Deepbit into adopting /P2SH/ and then outhashing other miners with Deepbit's share.

I'm not supporting /P2SH/ at this moment exactly because I don't want to be single deciding force and vote against majority of other miners.
(of course I don't like this "hackish" proposal too, and there are shady rumors about reasons for Gavin to support it, but I will implement it if significant amount of other miners will)

I don't actually think that this proposal can break something, but rather expect some better solution for this problem.
Well, I also believed that Gavin's OP_EVAL patch is good too because he is Gavin, and Deepbit was the first pool to support and vote for OP_EVAL. Until it turned out to be exploitable, buggy and not the thing Gavin really wanted. Luckily no harm was done, but lesson learned.

1 Objection: there are clearly no consensus between devs or miners about the exact method of implementing pay-to-script thing. That's the reason I would prefer dividing it into two separate stages - 1) implement plain multisig and long-address multisig support, 2) decide about pay-to-script method and move 1 into it.
This would give us both time for deciding on stage 2 and allow 2-factor authentication and escrow-services support with a small downside of using pubkeys instead of pubkeyhashes and a bit longer output scripts.

2 Objection: (less important) this proposal makes strange use of scripts: it's like having a compiler that can only allow the source to contain just one line #include "source2.c", which contains the actual script. Somewhat hackish. I would prefer either normal scripts or no scripts at all in TX's output.
Also I don't like the script to be in serialized form, but this is not a real downside at all.

3 Objection: I don't want to become the single entity to decide on this. That's exactly the opposite of what Gavin says. With current 2% of /P2SH/ support Deepbit would be the force to push /P2SH/ into existence, not the other way around.

What are you talking about? There has not been any real vote yet, what the network supports currently is not an indicator of what the support would be when the real vote starts. Right now the whole situation is a mess and nobody knows what is going on.

In the end the whole issue comes down to two things. Who am I going to trust more, the opinion of the developers or pool operators? I don't understand the issues with the code but I do know that it's the developers that have the best understanding. I do know that even the developers are not united in their opinion, Gavin supports BIP 16 and Luke supports BIP 17 etc.

So it's a complex issue but an even bigger issue is the power big pool operators hold over this. It's not just you Tycho but all the other big pools like Slush and Guild. This power has to be reduced, not for P2SH but for the development of Bitcoin in general. I hope everyone understands this.

Actually AFAIR, the "voting" ENDS 1 Feb.

Is it something along the lines of CIA remote-brainwashing peoples without them even knowing it?
That what I would think if I were a conspiracy theorist, but it seems too far fetched to believe... :)

I have a practical question though, when multiple public/private keys are used to produce a single bitcoin multisig address,
does it mean that all private keys originate on the same (potentially compromised) computer and then one of them needs to be transferred to a phone or another device? Or does the second key orginate from that second device? In this case what is the exact procedure to create a multisig bitcoin address for the end user?

Well, this just proves my point that the whole situation is a mess. The 2 percent support still doesn't tell us what the real opinions are, for example Slush has stated that he supports P2SH and his pool is much more than 2 percent. I'm not quite sure which BIP he prefers, however.

He is for BIP16.
And I don't know how he is going to mine enough voting blocks before 1 Feb.

No. Luke-jr initiated a rumor that Gavin is hired by some company going to produce hardware/software solution for 2-factor authentication and this is the reason he is pushing so hard.

Disclaimer: I don't think that this is true.

No, the whole point is in having private keys on separate devices.

Also, Gavin's signature says "Send Tycho a PM or email and ask him to support P2SH for a more secure Bitcoin" like I'm currently against "more secure Bitcoin".
But I'm not.

I think the deadlines are right now the biggest problem and many seem to agree with that. This has a very low chance of working out with these deadlines I believe, but there can always be a new vote.

BIP 0011 (https://en.bitcoin.it/wiki/BIP_0011) has been accepted and is already supported by the network - yet there are no clients that have a ui to construct Multi-sig transactions yet. Perhaps that should be priority? bitcoin-qt has no ui for constructing P2SH transactions. I also expect there will be situations where people try and send funds to a pay to script addresses from clients / exchanges that don't have P2SH support, sending the BTC into a black hole. I don't see the point in rushing it.

This is a good point. I'm not against you personally, I just believe it's unhealthy for a few individuals (including you) to hold too much power over the development of Bitcoin.

The same thing is true with Bitcoin that is true in politics, people who do not have power do not care and thus remain ignorant of the issues. Studies of the Swiss direct democracy system have proven that when people feel they have more power, they study the issues at hand much more carefully.

This is why it's in all of our best interest if miners in general become a bit more aware of their voting possibilities.

Actually I can manually ask many bitcoin developers with good reputation about what vote should I give, but there are 2 problems:
1) They possibly will be all for /P2SH/
2) This won't solve my goal of having better solution

Asking my miners to vote would be "democratic", but sadly they don't know what's the difference, how this will affect Bitcoin and will mostly fall for current FUD on the forum.
Surprisingly I got just only one PM asking me what I'll be voting for, so looks like most forum members don't really care or they believe that time will settle things.
(No, this doesn't means that you should PM me now :)

I hope people don't get turned off or frustrated by this process…that's exactly what this is, a process.  I think some people have allowed what should be an objective debate on technical merits to turn a little personal and have said things that they probably regret.  And people shouldn't allow themselves to get their identity wrapped up in a solution that they've proposed.  A rejection of a technical proposal is not a rejection of you as a person.  I have no reason to believe that anyone here is acting in anything but the best interests of bitcoin.


I want to voice my opinion against long-address multisig.  In my opinion, that's the last thing that should be implemented (actually, it's not the last thing that should be implemented…it should *never* be implemented…it's even more hacky than BIP-16).  P2SH is the proper way to handle multi-sig (and many other types of transactions).  And as I've said earlier in this thread, all transactions should eventually be P2SH.  P2PK (pay to public key…the current style transactions) is a just special case of P2SH.

Lastly, everyone should be in favor of implementing P2SH in some form.  The kind of transactions it enables will add great value to bitcoin.  In fact, if bitcoin doesn't do this, it will create an opportunity for a competing coin that does provide this innovation…this is the kind of fundamental improvement that could allow an alt-coin to overtake bitcoin.  So, everyone that has invested their time and/or money into bitcoin should be in favor to getting this implemented.

wow, i didn't know any of that. Bitcoin is a powerful technology that has potential for good or bad. That's for sure.
So, supposing that, if some entity realized that bitcoin as a whole is untouchable how would you get a grip on it ? Could be hard-coding a "new feature" that offers some control in the future like p2sh for example. If you ask me, bitcoin could be mass adopted in a year globally, but we would have a dumb'ed down version that only makes p2sh transactions, no way to change it and no way to generate an original address, that way we would pay forced heavy taxes to Governments.
Perfect central control without people able to protest with a policed world government. How would you push those small changes ? Having on your side their "leader" ? And if Bitcoin doesn't have a leader ? Nah, the people are too stupid to think for themselves they always have a one, real anarchy is a myth.

I know Gavin is a good person and i'm with him, not for long at this pace, but bitcoin is not his creation and he is just one of us. He states being thick-skinned and able to manage a project like this without issues but succumbs on the first occasion someone doesn't agree with him. People here posted some questions and concerns about the new "hackish" bip but he chooses go his way without addressing them properly. We're not programmers you know, so if one of them tells us Gavin is wrong there is a small chance him being right. So if more of them tell the same thing... meh

As I've been asking in other threads, but have yet to get an answer, I will ask here again.  Why is this such a rush?  Why the secretive "upgrade?"  What is wrong with this proposal that it requires it to be force pushed through at such a rapid pace?

This needs to be weighed and measured and the potential consequences thought out.  Why is this not being done?

This is one of the reasons why I understand that Gavin is trying to rush this. The whole development of this feature could stall for 6 months if we get tired of this debate and just forget about it. On the other hand if the devs can't agree on which BIP to use and neither do the big pool operators, we have a problem.

I have a hard time deciding what I would vote myself because the FUD that is spread over these different BIP's is getting to me. I have confidence in the devs but I don't know. The feature is so important but at the same time it's something that changes things a lot, so it shouldn't be applied lightly.

I just want to point out (before people get into a conspiracy panic) that this doesn't make any technical sense.  The address of a traditional, single signature transaction, is a cryptographic hash of the public key that is used for signature verification in the spend transaction.  The address of a single signature transaction implemented with P2SH would be a cryptographic hash of the public key + an opcode (OP_CHECKSIG or OP_CHECKSIGVERIFY).  The notion that you couldn't create a crippled bitcoin client incapable of generating original addresses is nonsense…governments would have to ban general purpose computers (hell, they'd probably have to ban handheld calculators).

0011 is being used?

I believe that without a deadline nothing would get done.

We could talk and argue and discuss for six months trying to find the perfect solution, and there would still be people saying that we need another six months to argue and discuss some more.

In fact, us developers HAVE been discussing and arguing about this for over six months now; this whole thing started with an impromptu brainstorming session at the first Bitcoin Conference in New York.

As for this upgrade being "secretive" : huh? It certainly isn't/wasn't a secret among the developers, and until the developers came to rough consensus (and I believe there IS rough consensus, despite what Luke claims) I didn't think non-developers would be interested in the technical details.

From some of the reactions in this thread, I think I was right-- most people don't care whether we use nails or screws or glue to build a better wallet.

RE: rumors that I'm doing this for some personal reason:  100% untrue. I want a solution because it will make Bitcoin better sooner.

I am looking at the distribution of hashing power controlled by the various pools right now.  Deepbit only has 35% of the network.  Maybe people finally changed over.


Tycho's opinion on the matter is good just as a general thing, but at these levels I don't think he can force a change if he disagrees.

+1 Actually the discussion is here for long time, but only the near deadline pressed people to talk about it more intensively.

Well, it isn't really a deadline.  More like a target.  And since we are already into the 7 day window and support has been underwhelming, I think it safe to say that the target will be missed.  So the debate will rage on while support starts creeping in.

I totally sympathize with Gavin though.  I've spent a lot of time on various committees, so I've seen firsthand that no group ever takes a task seriously until the last minute.

I want to try to clear up two misconceptions:

1. The original implementation of OP_EVAL was not "exploitable", but it did have bugs.  

2. The Feb. 1 deadline was explicitly designed to be a "soft" deadline; here is what BIP 16 says about it:

To me the biggest deciding factor here is what is the general opinion of the devs? Make a dev vote damn it, if at least 90% of devs agree on a BIP, tell us, the regular folk about it. I would gladly mine on a pool that supports that particular BIP if large majority of the devs are behind it.

It's not enough that Gavin claims that there is a "rough concensus" on something, we need more transparency. Most of the people who will vote for this thing, the miners, do not know about the inside discussions devs have nor do they have any idea of the actual differences in each BIP.

I think that the only dev against BIP16 is luke-jr, who is offering BIP17 instead.

And what about BIP17? I did get the idea that Gavin didn't like it, but what about other devs? If more devs like BIP16 than BIP17, then in my book we can rule out BIP17.

Also if it's true that BIP16 really had a large support and luke was simply loud about his disagreements, I would be willing to vote on P2SH via BIP16.

As I understand, there was a possible way to make pool's blocks invalid/orphaned, which can be an attack against the pool if this pool's rules state paying miners for invalid blocks.

BIP17 is less "compatible" with old clients and under some circumstances can allow redeeming other people's TXes if the network suddenly stops supporting BIP17.

But both BIP16 and BIP17 are incompatible with old clients to the enough level so we can't say that one is "significantly more" compatible anyway.

This might be an irrational fear though.  As a merchant and as an individual, you are going to want to accept only the transactions that are the most broadly marketable.  If there is even a subset of the population that enforces stricter rules about transaction acceptance (as is the case with both BIP16 and BIP17), it is in your best interest to adhere to that stricter set of rules.

Here's another interesting prospect…let's say both BIP16 and BIP17 were implemented in two different forks of the bitcoin client.  Since they are both somewhat backward compatible (which means that the old validation rules will allow these transactions to pass if seen in a block), both styles of transaction could be supported by the network as a whole.  As a person interested in seeing that all coins I receive are as broadly marketable as possible, I would want to have very strict enforcement of both BIP16 and BIP17 transactions.  There would then be demand for a client that could enforce both BIP16 (supports the funky, special case execution of code pushed on the stack) and BIP17 (supports OP_CHECKHASHVERIFY).  I'm not advocating this mind you.  I've stated my preference for the approach in BIP17.

No, Luke-Jr raised valid issues and that's a good thing.  However, he did it in a manner that pissed people off.  I only hope people can set that aside and evaluate his proposal on its merits and not discard it due to the manner in which he raised the topic.  I am very strongly of the opinion that BIP-17 is technically superior.  I only wish at this point I had more credibility to make this argument by having spent more time working on the core client.

Possibly won't work this way. With "old validation rules" 1) both BIP16 and BIP17 will be "non-standard", but mined by supporting pools (unless stopped by not relaying to to way to miner), 2) more importantly, if someone is mining by old rules, then under some circumstances he can create a TX, redeeming any BIP17 TX, that belongs to someone else, causing evil blockchain forking (depends on hashing power of both branches).

Hey Tycho, as long as you are here, I see that one of your objections to BIP16 is the magic transaction pattern.  Would you be more comfortable if there was an opcode that triggered the BIP16 mechanism?

I've seen that same objection from a few people, and I have to admit that I have quite a bit of sympathy for that view.

I suggested (https://bitcointalk.org/index.php?topic=58579.msg691937#msg691937) that we reuse one of the OP_NOPx opcodes as OP_P2SH.  It would remain very much like a NOP in that it did nothing direct, but it set a flag in the interpreter to tell it to invoke the P2SH mechanism if the rest of the script was valid.  Gavin wasn't a big fan (https://bitcointalk.org/index.php?topic=56969.msg697715#msg697715), but I think he saw it as pointless rather than harmful.  If the target date slips by without support (and it looks like it will), then it might become more useful.

Yes, I would be.

Also, you should note that I'll vote for /P2SH/ if considerable part of other miners will. It's not like I'm completely against it.
My position is rather "Vote for doing it in a better way unless impossible" and not triggering the avalanche by voting myself first.

my opinion is similar to steve's
BIP16 does look like something that can cause trouble down the road
1) the way i understood it, BIP16 pushes something on the stack as data and the executes it. Executing data is something i was taught to avoid at any cost
2) BIP17 looks like a more elegant solution that better fits the script's design.

but i am still concerened about possible security issues BIP17 might bring right now..
maybe the solution is wait till somebody has a better idea

CHV (BIP17) also executes data, as does OP_EVAL (BIP12).  The debate is over how to execute the data, not whether to execute it.

the way i see it BIP17 hashes code rather than execute data, but i guess its semantics

Sigh.  They all hash code and they all execute data.  The hash is used to verify that the data executed was the data intended to be executed.

BIP17:
   scriptSig: [signatures...] OP_CODESEPARATOR 2 [pubkey1] [pubkey2] [pubkey3] 3 OP_CHECKMULTISIG
   scriptPubKey: [20-byte-hash of {2 [pubkey1] [pubkey2] [pubkey3] 3 OP_CHECKMULTISIG} ] OP_CHECKHASHVERIFY OP_DROP
code is in green data in black. at what point do you execute data?
BIP16:
   scriptSig: [signature] {[pubkey] OP_CHECKSIG}
   scriptPubKey: OP_HASH160 [20-byte-hash of {[pubkey] OP_CHECKSIG} ] OP_EQUAL

data in bold is being executed
this is semsntics. you can call everything in both sigs "data" and be done with it.

What about this argument below from Stefan Thomas:


Quoted from here:
https://bitcointalk.org/index.php?topic=60433.msg714522#msg714522

Volunteer organizations all suffer the same affliction. A few people do most of the work, but when it comes to making decisions, people suddenly come out of the woodwork. If someone doesn't make a decision, then nothing gets done. That's why most organizations have elected leaders whose votes tend to count more than others. I think it's great that this is an open voting for miners and pools and I'm not discounting their work, but the real volunteers are the devs themselves. I thing the devs should take an opinion poll about changes, but ultimately they should set the deadline and have the final say. Anyone else can start their own fork and start their own volunteer network.

There are many interesting and stimulating posts in this thread, and Gavin's OP was very well written; I would have liked to respond to several but I don't want to spam/dilute this thread. So I'll limit my response to this one. First, a disclaimer: I do not mine at Deepbit; I never have. I have nothing against Deepbit or Tycho, it is merely my personal choice.

Tycho, your point is absolutely valid. Asking for a 'vote' of the general mining populous on BIP16/17 is pointless. Yes, it is democratic. But in this case democracy wouldn't be wise. Most people are not in a position to know, or understand, or don't want to understand, or are incapable of understanding, the fundamental differences between the two proposals. Why one is 'better' than the other.

Essentially most of us are sheeple that will vote based on what other sheeple are doing and FUD.

I am not a dev, but I also don't consider myself a sheeple. I am able to realize that my vote is meaningless; I simply don't understand the technical aspects of the bitcoin protocol, nor do I understand the technical ramifications of each of the competing proposals. Perhaps one day I will feel confident enough to voice my (educated) opinion. But that day is not coming up any time soon.

I would think that most miners are in the same boat as me. They, like me, shouldn't be voting. IMHO the only people qualified to vote are the devs. People who truly understand the protocol, how it works, how it can break, how it can be exploited. Only the devs are in a position to truly see the advantages/disadvantages/risks of each of the 2 proposals.

This is why I say that the only people qualified to 'vote' are devs (rather, more accurately, people who have a deep understanding of the existing bitcoin protocol and underlying codebase). I trust that enough of them are unbiased, with no hidden agenda, and are truly motivated by a pure desire to better the bitcoin network. All that is required of them is to be courageous enough, mature enough, to discuss, present, review, and reach concensus amongst themselves.

We are all part of the same network, the same community. We are not competitors here; there are no 'bad guys' and 'good guys'. It is healthy to have different opinions, but it is also important to be able to see when that is being taken too far. If the majority of devs are pushing for one implementation, and a minority are pushing for another, the minority needs to concede and allow development to move forward. Otherwise nothing will get done. And this harms all of us.

the problem is the devs seem to disagree
If they could agree on a solution among themselves - non of this would have happened
Of course at the end they are the ones who have to decide, but they can still ask the public if they want to. and if asked the public is allowed to state his opinion, no matter how stupid it may be.

You can not have a proper vote where if you do nothing a vote is counted one way, and do something (hard) the vote is counted the other.  You are going to get a # like 2% out of that. 

A proper vote would be people put in a code if they are against it, and a code if they are for it.  Can you imagine if the only way we passed a law was if we needed YES votes totaling half of the population and made it so that the vast majority of voters would not have the technical skills to vote?

this is actually good - because this is a vote on a technical issue. if you cant apply the patch you shouldn't vote.
the default "i am against the change" is a problem. but the tag was never intended to be used as a voting system. The tag's meaning is that your miner is technically able to use the feature.

Since we're trying to keep this non-technical (I'm not sure that's a good idea, so click the links if you can handle the details!), I'm going to try to come up with a more accurate analogy:

• BIP 12 (OP_EVAL) (https://en.bitcoin.it/wiki/BIP_0012) is inventing a touchscreen for your home security system. You can basically do whatever you want with to authenticate.
• BIP 16 (https://en.bitcoin.it/wiki/BIP_0016) is inventing a camera+touchscreen, but due to patents/closed-source or whatever you can only get it from one security company, and can't use any other security system in combination with it. Everything must be done through the touchscreen.
• BIP 17 (CHV) (https://en.bitcoin.it/wiki/BIP_0017) is inventing a lock mechanism that can be opened by not just the old flat keys, but also by various combinations of any of these old keys or pretty much anything imaginable, without an abstraction layer like the touchscreens.
  

Slush indicated to me that he isn't interested in researching the options, and will just go with whatever Gavin tells him to do.

This was mere speculation in private, IIRC when asked why Gavin is rushing things. I have no evidence, and haven't even looked at TruCoin's website to see if this might possibly be the case.

This applies to Gavin as well. "I'll just go with what Gavin says" is a bigger problem than "I'm mining on Deepbit" right now: DeepBit at least cut down on advertising due to concerns of the centralization, but Gavin seems to be encouraging the "just trust me" attitude.

No, BIP17/CHV does not execute data from the stack as BIP 12 and 16 do.

One problem IMO, is that Gavin has merged BIP 16 into git master, and set it up to force everyone using it to vote for it. To not vote you have to patch your client. I submitted a fix to make this optional 2 weeks ago and while he did say he'd accept it with a minor change a week ago (which I made immediately), it still isn't merged.

---

For the record, I agree with the many people who think we should give this more time. However, my interest is only in avoiding the deep protocol change that BIP 16 makes, so I am fine with compromising on getting BIP 17 deployed sooner.

Also note that while BIP 16 might arguably be slightly simpler/deterministic in the specific implementation used in Bitcoin-Qt, BIP 17 is almost certainly generally simpler to implement, and in practice much simpler in terms of backports to bugfix-only bitcoind and Bitcoin-Qt clients.

(accidentally posted this in the other thread)

Steve, don't both BIP16 and BIP17 satisfy your complaint that the scriptPubKey should not contain the rules for redeeming a transaction, only the script hash to be validated upon redemption?

Current:
scriptPubKey
scriptSig

BIP16:
scriptPubKey
scriptSig

BIP17:
scriptPubKey
scriptSig

So does the BIP16/BIP17 argument come down to whether the validation script should be encoded so that a new opcode is not necessary, or to introduce a new opcode so that encoding is not necessary?

I agree that asking which BIP to enable from the miners is stupid, a very large majority of them don't have a clue. But my point in all of this has been that most pool operators do not have a clue either which means that it's good to raise the awareness of all miners over this issue.

As far as the "just trust Gavin" issue is concerned, I for one don't think about it that way. This is exactly the reason why I want more transparency from the dev team. The dev team should be the one handling this. Vote amongst yourselves and come up with a compromise. A small minority must compromise if we want to make Bitcoin more than it is now.

So in conclusion I will list these following scenarios and if it's a problem:

A) Gavin says do what I say even though a good number of devs are against it and people still trust Gavin -> this is a problem
B) Gavin says do what I say and a large majority of devs agree with him -> this isn't a problem unless the minority is too stubborn to compromise

Based on what I've read in the forums, we are clearly at scenario B. Not a problem unless minority refuses to compromise. Clearly there is no compromise, yet. Whatever the scenario is, we need more transparency. Developers need to suck it up now, eat their pride and start coming up with answers among themselves.

I think we might be overstating the significance of this.  I agree (as I've stated) that pushing stuff on the stack and executing it is not ideal.  Neither is having special transactions with special rules that apply to them.

However at the end of the day this is a tactical step.  I think there is a growing awareness that P2SH in general is the way all transactions should work.  Neither BIP-16 or BIP-17 are a perfectly clean solution when viewed in that light.  I think the ultimate deciding factor should be what's best from an upgrade perspective and from a safety perspective.  As I understand it, there aren't a lot of tests around the scripting engine.  I'm not at all familiar with the implementation of the scripting system.  If there is something about BIP-17 that requires it to execute largely unproven code paths, that may be the deciding factor in favor of BIP-16.

As for the urgency, the danger I see is that an alt-coin implements this instead of bitcoin.  If bitcoin takes too long to add these capabilities, then an alt-coin could do it and then everyone would eventually move to that alt-coin.  I don't think we need to rush, but at the same time, we should take this opportunity while it's at the forefront of a lot of people's minds to make a decision and move forward with it.

My advice to the devs is to do the safer thing recognizing that the scripting system doesn't have a very good safety harness in the form of being well understood by a lot of people or in the form of a large amount of unit tests.  I've met Gavin in person and my opinion is that bitcoin is lucky to have him (both for his technical skills and for his approach to leading a project like this).  When he voices concerns that we need to be very careful about going down certain code paths…that they aren't well tested or well understood, I think we have to take that seriously.  I can't see anything about BIP-16 that is any kind of threat to the future of bitcoin.  Nor does it preclude a day when we could move to a more robust and simpler scripting system.

technomage
this majority/minority of devs makes no sense for this issue
If even 1 of 10 devs thinks a certain solution is insecure/bad for the system - it should not be implemented
This is not deciding what color shoes you should buy. this decision will have implications on the future
you must learn the technical side of both arguments to understand what it is all about.
btw, I think both solutions are not good enough. And no i dont have a better idea.
but if i had to choose now i would go with bip17 - due to elegancy

But the thing is BIP16 is not insecure or bad. We're talking apples and oranges here and I've come to the conclusion that there is really nothing stopping us from implementing BIP16 except the stubborness of Luke-Jr. Pretty much all the other devs agree that it's a good solution. BIP17 isn't bad either but I don't think the support for that is as good as it is for BIP16.

This is the only viewpoint I can have on this because the technical details are not something I understand. But I think it's valuable because it seems that the answer to this problem is not going to come from the technicalities, that discussion has been in the apples and oranges stage for a while now.

i think both implementations have their problems and this is why gav opposed to bip17 and luke opposes bip16...
So why not listen to both of them?

Why must it be unanimous? One vocal minority really shouldn't be bringing things crashing down like this.

Insecure is a completely different argument than bad for the system, so I would appreciate it if you kept those separate.

If we are so worried about the size of the blockchain, it appears to me that BIP_17 is not the way to go because of increased amounts of data being stored in the chain.

As for the "dear leader" complex that has been alluded to in this thread, I think that is a fallacy - most of us have seen for ourselves the capability and openness with which the current project leader has had and has conducted himself with, and for that reason only, there is support.

The main problem is that it's an irrevocable change to the block chain if something goes poorly.

I think this is going to be an issue with any implementation allowing payment to a script hash, and I agree with others that this is the correct way to go moving forward.

as far as i can see it is true for both BIPs

In the current setup, scriptPubKey is the code, and scriptSig is the data.  If BIP17 isn't executing code by virtue of reclassifying scriptSig into "code", then none of the others are either.

In my view, the script in the transaction output is "code", and whatever is needed to redeem it is "data".  By that definition, all three are executing data.  If you prefer to think of things that are executed as code wherever they may be, then none of them execute data, but that is pretty silly, since it would reduce your credo against executing code into "be careful that you don't execute things that you don't execute".

Watching.

look at how Gavin himself wrote it in his post:
https://bitcointalk.org/index.php?topic=60433.0

OP_HASH160 <hash> OP_EQUAL
OP_0 <signature> OP_PUSHDATA(2 <pubkey1> <pubkey2> 2 OP_CHECKMULTISIG)

the code is "OP_PUSHDATA"
"2 <pubkey1> <pubkey2> 2 OP_CHECKMULTISIG" is data
then, this previously pushed data gets executed

while in BIP17:
<hash> OP_CODEHASHVERIFY OP_POP
OP_0 <signature> OP_CODESEPARATOR 2 <pubkey1> <pubkey2> 2 OP_CHECKMULTISIG
no tricks are used...

my problem with the idea of executing data is that it is the basis of a lot of hacks in other software

BIP 17 transactions use less data than BIP 16.

Except scriptSig is not and has never been mere data, it is code.

So, your objection is to OP_PUSHDATA?  I only bring it up because BIP17 does that implicitly.  It bangs both parts together and executes them as one.  Go dig for Gavin's objections to BIP17 where he explains that bitcoin used to work this way, and why it does not today.

AFAIK bitcoin still does exactly that.
puts the signatures together and executes the result
both signatures contain both data and code
my objection is not to push data, but that this data is being executed at a later stage

https://en.bitcoin.it/wiki/Transaction
also look at the examples there

I don't understand the technical details here... at all... but I find it fascinating to read these kinds of conversations. This stuff is so damn cool.

I'm confident from fiery debate, reason will emerge. As an onlooker, I'm continually impressed and bewildered by the brilliance, creativity, and passion of those developing the core of this new world.

Cheers to you guys.

"average" miners, for all practical purposes, can't vote anyway... A solo miner isn't generating blocks fast enough to make a difference... so even if every miner popped up with a vote for P2SH, it wouldn't really change anything.  

The "vote" comes packaged in a solved block.

and your point is, Holliday ? this is a free market you know, grasp the concept

back on topic, I know this can be very frustrating for you Gavin but you will manage to reach consensus, i'm sure about that.

The regular pools should have at least made a poll on their site. so its not the manager who decides, but the miners of that pool

I am not sure why [Tycho] is being bashed for being completely agnostic! Sure it is a large amount of hash power, but instead of forcing his users to "vote" by modifying his blocks, he is instead doing nothing. I don't see how this warrants significant hate, because I am sure that voting one way or the other would just mean that many more people crying foul because it isn't they want they want it to be.

[Tycho]'s previous mentions of selling shovels to the miners have piqued my ongoing curiosity, and I can't wait for the next big thing to come along.

Anyone else find it strange that Gavin would put this up to a vote with maybe two weeks notice, where no vote is the same as a "no" vote? With apparently most miners not even knowing how to vote? And the excuse that "if you don't know how to modify your client, you shouldn't be voting anyway" just resulting in an inevitable conclusion of almost no votes for it at all?
Two proposals:
1) Scrap the deadline, put up instructions on how to four for BIP16, BIP17, or neither, in a simple to understand way (precompiled bitcoind exe's preconfigured for specific votes maybe?), and just let the voting continue. Eventually once more than 55% of the miners are voting for either BIP16 or BIP17, implement the winner. With enough time it will happen.
2) If miners, despite securing the network and being the gate keepers to any changes, "don't understand the code anyway, and shouldn't be voting," which I sort of agree with, since I don't understand this completely, and don't think these important decisions should be turned into a popularity contest (disclosure: I like Gavin, I really don't like Luke, but what kind of people they are should have no bearing on their coding skills, of which I am not well enough informed), then don't vote. Gavin can push out his client, Luke can push out his. People will vote with downloads, and the stubborn ones will have to switch eventually. It will be forky and messy, and people may lose mining revenue, but Bitcoin will survive, especially in at this still early stage. It will also be a good test of how well Bitcoin will handle necessary radical changes, and we all know those will have to come eventually.

Rassah, that doesn't really address the problem.  99.9% of miners will not get to vote, regardless of what they change their clients to.  All "votes" are packaged within a solved block, thus you must solve a block to "cast" a "vote".

this was not intended to be a vote...
people started interpreting it as a vote when luke came up with BIP17

I think i had enough of this. Let gavin and luke fight to the death. the winner writes the P2SH implementation

No, the BIP makes it sound like a vote.


Rightly or wrongly, that is the root cause.

supports here is "technically supports" as in "able to accept and process such transactions". not support like in politics

Edit: the concern was that most people wont update, because even now more than half of the clients are below version 0.5

I disagree... but we've already covered that in another thread.  If, in fact, it is to show technical support, then the BIP is wrong.  In either case, it is immaterial to this discussion. 


Is a false statement was my point.  People started interpreting it as a vote because of the BIP.  Perhaps the argument could be made that Luke increased awareness, and that I would agree with.

Doesn't works this way. "Voting" means that this mining system already supports given method, but it will be enabled only after specified date.
If you want to vote for one version, but in case of other one winning switch to the other, you need to implement BOTH with a some kind of switch. And this switch should never br triggered after the end of this voting. Adds complexity and poosibly error-prone.

There can't be a democracy if the vast majority of those with voting power are ignorant on what they're voting for.

I find it interesting that major changes were implemented to the client/protocol that helped pools before we started considering changes that would help the common bitcoin user. That is probably something that is endemic of our society. Helping the big interests in a society first makes it more difficult to implement changes for the betterment of all stakeholders.

I would like to point that BIP17 has no chances of winning.
The question is WHEN bip16 will be over 55% and starts working.

well if you say so....
Thats already 40% of the hashing power.
What exactly are you waiting for before you enable the support in your pool?

I agree 100%


What are you referring to here?  BIP 16 (or 17, or 12, etc..) have no benefit to pools and everything to do with miners.

I'll start working on it when I'll see significant support from other miners. (2% is not significant)
BTW, according to Gavin's e-mail today, Deepbit is 28%, not 40%.

I'm saying that BIP17 has no chances not because of me, but because I seriously doubt that it will be supported by anyone besides Eligius.

i'm not a bitcoin dev, but i was already involved in many projects. from what i read here, i think the best way is to go with the proposal that has been tested at most so far, and most of the devs have studied the actual implementation. the reason is that in that case most of the current devs know about how it works, what its implications are and about the possible pitfalls. also, even if another proposal is better on paper and in theory, what actually counts is a very good, well tested implementation, it needs to be implemented near perfectly from the start! in that light, a superior theoretical approach, only checked by a few, will be much worse.

and yes, this means it could go something wrong, but that won't kill the internet and it won't kill the blockchain. a new client version will fix that -- and that's only the unlikely worst case scenario.

thats a deadlock
the others are waiting for you

There's no incentive for others to wait or switch. Why would they be waiting for Deepbit?

I'm talking about support from other pool operators.

To what are you referring?

psychological reasons.
he's the "leader" of a big chunk of the bitcoin network
people will assume that he knows what he's doing and that after having 40% of the hashing power the full support for bip16 will be soon enabled.

That's complete nonsence. Why would they wait for me ? Just because of Gavin's words about me ?
slush and BTCguild combined are more powerful than Deepbit and they are working on it already.
I don't see any point of being first, and I think that I must never be the first.

I'm not the only one who concedes BIP 17 is better than BIP 16, and certainly better than nothing. Hopefully the pressure to rush BIP 16 will lighten up after it fails to meet its voting deadline, and people who just want P2SH rushed in will realize BIP 17 is not delaying things.

I'm pretty sure Tycho is aware that his hashrate has been dropping for quite some time before BIP 16 already. There's no reason to think people are switching over this issue in particular.

---

Gavin, I would appreciate it if you would stop emailing other pool operators in secret to try to convince them to support BIP 16 (or at least stop with the FUD I've been hearing). Is there a reason these emails can't be posted openly?

Specifically the ability to reward the generated coins in a new block to multiple addresses, thus making it easier for many new pool operators to payout to their miners. I recall that being a significant boost to the pool op community.

Except that still hasn't been merged, though it should have been by now considering it has been well-tested for over 8 months and has zero effect on anyone who doesn't want to use it... There are also other mining-related improvements that should be, but also haven't been merged, which are needed to solo mine too (all bitcoind releases so far cannot handle the load required to solo mine). I'd like it if I (or someone else qualified) were allowed to maintain solo mining, at least until p2pool matures enough to be a viable replacement for solo mining, but the developers with push access seem content to let it stagnate until finally removing 'getwork' entirely in the future. But this is really getting off-topic IMO...

Well, may be Gavin did it intentionally, trying to force me into joining efforts with you and thus cause a major split in pools/devs team to weaken the bitcoin community ? :)
Who knows what he really wanted...

I had no doubts about someone not getting the joke.

But yes, much less than 5 induviduals can weaken the community, and it's not the pool owners, of course.
At this moment it was only a small confrontation between Gavin and Luke-jr (but Gavin attacked me too while I did nothing wrong).
Imagine what can happen if 2 or 3 core devs will have a fight over something ? That's exactly why I hope some new full clients will appear, like Ufasoft's one, but opensource.

I apologize-- I did not mean to attack you, I thought I stated nothing but facts. I am also sorry I didn't speak up about some of the things that were said about you earlier in this thread (e.g. suggesting an attack on your pool is NOT cool) but I don't have time to read every forum post as soon as it is posted...

I did. That's why I started my own pool. :P

I'd like to see what [Tycho] said.  ???

I say the core dev team need to play hard ball on this.. Make the change they agree is best, if Deepbit and other pools don't upgrade to the latest version then I assume the blockchain will fork, with official clients going one way and the pools going another.  The difficulty will plummet on the official chain and mining will be very profitable for the official client users.  The mining pools can keep pushing forward with their forked chain, but for how long? with no development it wont last long.  If enough warning is given to official client users that x, y, z pools will not be sticking to the official chain, then they have a chance to mine somewhere else or solo mine at the cut-over date.

If Bitcoin cant resolve this issue with a majority (peers) rule, and 6 pool operators can dictate the rules then the project is in trouble anyway.

Don't worry, this likely does not happen. Nobody want to work on forked chain alone...

^ This. If this whole thing has proven one thing it's that Bitcoin is a pain in the ass to change in any way, and that's good. Stability is good.

Simple-minded thinking from the likes of Rassah. What a surprise.

In the world of electronic devices, stability can be an ominous sign. Companies that don't adapt well-liked products to changing conditions get steamrolled. Think Nokia and Blackberry. In financial services, stability has a better reputation. Bitcoin is at the intersection of the two.

Regardless of what you think about stability, it is clear that miners have way too much power for bitcoin to be governed well. In most respects, the opinion of miners is neither here nor there as far as bitcoin's future goes. They are not the same people as long-term bitcoin holders and bitcoin business operators. The latter groups have a clear long-term interest. The miners do not. But miners are afforded all this authority. It is like asking the electorate of Bolivia to choose the US president. One wouldn't expect the Bolivian electorate to be highly motivated to participate in the election, or if they do participate, to try and make an informed choice.

Finally, given that miners make decisions, it is best for them to be made by miners with substantial market power like Tycho. At least these guys will care somewhat about outcomes. Moreover, if some emergency happens it will be much easier to mobilize a small group of oligopolists to respond. Small miners won't care enough to even think about the issue, let alone download an update.

*cough* um...  ???


Stability for new features = bad. Stability for underlying protocol = good. How much has SMTP, FTP, and even HTTP changed in the last 20 years? Sure the last one got a lot of new features, but overall, not much. We don't want actual money changing around too much, since stability = predictability.


Actually a closer analogy is like having the US president veto ALL new laws passed by an almost evenly divided congress. Nothing will pass, and no new changes will be made unless people REALLY REALLY REALLY want it. In this case, miners really don't care about change. They have their equipment set up in a certain way, and changes only mean extra work.


Why? a 3% mining fee is a 3% mining fee regardless of the protocol changes. Why would Tycho or any other miners care?


Hmm... that's true...

You are missing the point. Miners' self-interest is not intrinsically linked to bitcoin's long-term prospects. They are asked to make a decision affecting bitcoin's long-term prospects. They don't care. Surprised? You ask them to behave responsibly and they will.... wait for it... NOT FUCKING CARE!

Good luck exhorting them to take up their responsibility. While you're at it please exhort the speculators not to short sell. Also, consider the malware programmers. They could use some serious exhortation as well. Clearly the problem is that everyone needs to hear more wholesome exhortations about responsibility. Should put up some fucking loudspeakers outside to broadcast them like in communist countries. If you are really an exceptionally dirty bastard, encourage people to attend church to get it in the ear from those child rapists.

Disclaimer: I may seem to be reacting strongly. For an economist, "Claim that outcomes would be different if everyone just behaved more responsibly" = "noises associated with child-rape". Profoundly distasteful. Difficult to distinguish the two behaviors.

I think there can be a major problem if Deepbit agrees to work with another pool or gets 51%
It will be possible for them to set the transaction fees to 1-5BTC/kb and reject any block that was not created by them.
I think this is a lot worse than the 51% double spending problem Satoshi described
And the miners might not leave - they will be making extra money from those fees.
This is sort of the reason monopolies are illegal in most countries. when a large group agrees on a price - that group can get almost twice the profit - at the expense of the users.
Even if tycho won't do something like this, somebody needs to hack just ~2 servers to achieve this goal.
Bitcoin will become regulated...

Edit:
just to be clear. i dont think the pool managers are the problem. the miners are.

Because 3% of $5 is less than 3% of $20.

Ridiculous. Idiotic. Insert additional expletives. This is like blaming the other people on the road when there is a traffic jam. Or like blaming other orange growers for selling oranges for too low a price during a good harvest year. Learn some fucking economics or STFU.

There is free entry and exit into mining. There is relatively low cost entry and exit into pool management. The decision-making patterns of miners and pool managers are determined by the protocol. It is nonsensical to blame miners, pool managers, etc.

The protocol is the only primitive of the system. Nothing else has a causal role. If there is any problem, it is a problem with how voting operates in the protocol.

I dont see how your response has anything to do with my post. read before you post.
if somebody is standing in the middle of the road and creating a traffic jam - it is their fault, but i dont understand the analogy.
so who do you want to blame for Bitcoin centralization? the economics? the bitcoin protocol?
Or do you thing that centralization of bitcoin is not a problem?

Wow. You just don't know anything about economics. It's okay. Just flush the shit out of your brain and I'll drop some knowledge in it instead.

Whatever the outcome is. Only the protocol is to blame.

If someone sits in the road blocking traffic, it is because there is no system in place to sanction people who sit in the road blocking traffic.

The protocol is the system.

The miners are just regular guys. You could purge all the miners and bring in new people. The new people would adopt the same pattern of behavior because they would face the same incentives. The incentives are structured by the protocol.

are you serious?
To blame the protocol is like blaming a gun for murder.
The protocol is a tool.the miners and traders are the ones making the decisions and steering Bitcoin to what it is today and will be in the future.
this has nothing to do with economics. People should be responsible for the conequences of their actions and not blame the tool they used to do that.

edit:
not only that, the miners have control over the protocol. if the miners decide not to support a part of it (like what is happening now) it wont be in the protocol.

Aside: It is so much more difficult to educate people when you can't threaten to fail them for failing to conform to your world vision.

so educate =  conform to your world vision ?
"anyone who is n't agreeing with me is stupid and wrong"
nice :)

So true. (As suggested by picture and motto.)

i dont know if to laugh or cry

Yes, but now we come to an interesting issue in theories of innovation.

Changing the protocol is difficult (synonym costly). Therefore, the initial choice of protocol can have a long term impact on the evolution of the system. Start from a bad protocol and you can end up stuck with a bad technology for a prolonged period.

This is not true with miners or pool operators. Bad miners and bad pool operators face competition via low-cost entry and exit.

Entry and exit for a protocol is possible, but it is a big, time-consuming, and costly endeavor. Changes to the protocol are the control instrument here.

Most Importantly, the fact that miners control the protocol is a central feature of the protocol [central flaw would be more apt].
This can and should be changed.

That's the whole point of monopoly - no competition. any new comer can join the monopoly. if he wants a short term profit he won't join, but in the long term it will be beneficial for him to join - less risk, almost guaranteed profit. thats why new miners join deepbit by default

How can you take the power away from miners in a protocol that relies on computing power for its security? To make such a change you will have to reinvent the core principles of bitcoin.

edit: i do agree the the power miners have over bitcoin it too big, but i dont see a way to "fix" this

I think this topic has derailed a bit thanks to cunicula, his arrogant and in my opinion ignorant approach isn't helping much. Comparing traffic jams with Bitcoin mining is a very bad analogy, traffic jams are clearly a symptom of a badly designed traffic system, with Bitcoin mining it's different. It costs people very little in either money or convenience to fix the problem of excess centralization. With car traffic the situation is very different.

I find it funny that cunicula is claiming here that people don't understand economics when I think he's been learning from a clueless mentor. It has been proven over and over again that people are not "rational" when it comes to their decision making, it's more complex than that. Feelings and more important than that, values, matter a lot when people make economic decisions. These factors can be affected by raising awareness, or educating people.

However with mining we can assume that a good number of miners are mining only because of the profit, they do not really have an ideological feeling about Bitcoin or something like that. Even those people should care about this if they are economically rational, their business is at stake here. Not only is centralization bad for the security of the network, now it has been proven that the whole development of Bitcoin is at stake here and that could significantly affect the competitiveness of the whole technology. All this affects price which affects miners.

I believe that this issue is one of the factors that have caused a recent price dip. In fact it will have a significant effect for the whole future of Bitcoin depending on how the whole issue is solved and how it affects future decision making. My personal opinion is that everything went wrong the minute this whole thing went public like this. The developers should be able to make a decision on this and then present it to the public as the solution, which undoubtedly people will accept. I know that they were unable to do this but bringing it to the laymen so to speak is most likely only going to bring the ball back to the developers.

The good thing about this is that the devs have had some feedback from technical people who are not part of the core dev team, so that's probably helpful. Clueless non-coders speculating on the whole thing is not helping at all, it's clearly just adding doubt to the whole development of Bitcoin. I'm not calling names again but I think some devs need to start compromising amongst themselves if they really know what's best for Bitcoin.

+1

It's absolutely erroneous to think that it's not an incentive for miners to improve the way we mine. It's not only about direct profit, if people want to see mining and the network itself as a healthy business environment in the long term, it must be developed and it can be developed by anyone. This has been proven first with people starting pools of their own that have succeeded as smaller pools. Now mining has evolved again with p2pool. I'm confident that p2pool in the way it is now is not the end game either, we will go forward.

Your computer science training has equipped you to analyze decision-making behavior. Certainly wouldn't want any input from a fucking expert who specializes in studying rational decision-making. Those idiots with their mathematical models of rational decision-making and statistical skills don't really count as technical people. Business never try and make rational decisions anyway so what is the point. Incentives don't matter. It's open-source, duh?

What a fucking idiot you are.

I don't value people like you very much, you're lacking something I tend to value a lot which is communication skills. As far as the issue is concerned, you're again clueless. Incentives are everything but the problem is that if you only take into account monetary incentives, you're basically stepping off a cliff. This might apply to a large corporation that bases everything on numbers, but for a regular consumer the incentives can be very complex. In fact they are too complex to be able to model accurately with any current science or technology. You can get accurate results in very specific scenarios where a limited set of incentives have a major role, but that's it.

Bitcoin mining is something that can be called very complex, there is no average miner mindset. You have miners who use Bitcoin for more than mining, miners who don't. People who have ideological feelings for Bitcoin, people who don't. Small miners, medium sized operations and mining businesses. People who hoard their bitcoins and people who sell them all. And everything in between.

All of these people should care about these issues because it affects the long term profitability of Bitcoin mining. Not all of them care because many are only concerned about the direct profits, but through raising awareness and educating people it's clear that people change their behaviour. The pool pie has already changed quite a bit because of the concerns over 51% attacks but it's still too centralized, this recent issue highlights that.

One of the biggest issues in the world today is short term thinking. Companies care about their quarterly profits while the thinking of miners seems to be even more short-sighted. If they thought about the bigger picture a little more they would understand many things, first and foremost that variance in mining goes way down over time, you don't need to mine in a 1000gh/s+ pool to get very low variance. Second, they would understand that what happens in the Bitcoin world affects price which affects their mining profits so they should care a little more about what's happening.

I've actually studied incentives quite a bit but not from an economics standpoint. To read more on how incentives really work, based on real science, I can recommend this book. For everyone. http://www.amazon.com/Drive-Surprising-Truth-About-Motivates/dp/1594484805/ref=sr_1_1?ie=UTF8&qid=1327661332&sr=8-1

That book is not exactly about consumer or business incentive, more like employee incentive. But it proves nonetheless how flawed the thinking regarding incentives really is, especially in economics and business.

In layman's terms:

They want to happily charge you more fees.

why are you concerned about giving a lot of power to pool managers but not about giving a lot of power to miners in general?
Isn't it the same thing on a different scale. Most Bitcoin users aren't miners ( same as most miners aren't pool managers), yet the miners can set the transaction prices to whatever they want, they can force a protocol change or shutdown the network altogether. they have the incentive to make the "right" decision, but so do the pool managers.

Nice. Thanks for bringing us back to the real world.

Wow did that ever go off course, WTF was I going to respond to after all that?

Yes, blaming the children for what some priests sometimes for some time get away with is not quite right.

But does it mean the Pope is a pederast? I'm not sure that follows.

Lets go back to basics. Decentralisation. If I want to decentralise, should I listen to the chap who hangs out with the C.I.A. or the raving religious nutbar who actually and possibly unfortunately can be amazingly on point when its not a question of how many angels can dance on the head of a pin or some other theological debate?

I think maybe I need to hear/read again Luke's argument(s) against BIP16 as it seems to me that if Gavin's arguments against BIP 17 were as cogent as he seems to think, Luke would have recognised that fact by now. It is not, afterall, a religious matter. (Is it?)

Presumably Luke has heard all Gavin's arguments, yet they have not convinced him. That worries me, as I have not yet found Luke to be a nutbar in such fields and dismissing people's expert opinions on account of their extra-curricular nutbarism is not something we nutbars particularly approve of.

-MarkM-

Speaking as a poorly informed layman, it could be that the choice is not too important. In many cases, one expert will get become irate with another expert over a pretty trivial matter. Then the controversy will escalate, potentially developing into lifelong hatred. If the argument occurs within a team, the most important thing is preventing this kind of escalation.

One possible approach would be to admit that neither change is perfect, and to go with one of the two options as an explicitly temporary fix. In this case, the losing party would know that their views have been acknowledged, and that there is a plan to address their objections in a future revision.

 

this is impossible for both proposed solutions.
dropping support for any of them in the future will make any transactions made in the past redeemable by others

+1

There has to be some kind of compromise. As far as updating the system in the future, I am under the impression that BIP16 is more compatible with that. I don't remember which thread it was or who said it, but I remember something like that.

I think I might be with Luke on this insofar as BIP 16, but not sure yet about BIP 17.

I realise we are stuck with an already-existing blockchain.

But there seems to be a difference of opinion on whether in an ideal world an ideal blockchain would use scripts or simply an enumerated list of "special cases" aka "use cases".

I seem to recall Luke having implied somewhere that if we are going with a special case (which Gavin's approach seems to be), instead of with a generic scripting language (as Satoshi envisioned and implemented) we should do so for real, committing to moving to a future in which there will be no generic scripting, simply a list of special cases aka use cases. I seem to recall Luke also complaining that Gavin was refusing to make such a commitment, seeming to want to just hack a special case on top of the existing script language leaving us with a bastardised combination that is neither cleanly a scripting language nor cleanly an enumeration/list of special cases.

Evidently Satoshi was not scared that his scripting language would turn out to be full of ghastly exploits.

Was it?

Were the disabled scripting terms disabled due to actual exploits having been seen or simply because others were not as confident as Satoshi that the specific capabilities Satoshi intended were safe?

What does a general scripting language buy us, really? Flexibility, maybe? Couldn't simply adding yet another special case each time a use case is found that existing enumerated cases cannot handle equally well allow flexibility, while also providing assurance that only flexes shown to be safe can happen due to each case having to be explicitly included by the devs instead of brilliantly discovered as already possible by, potentially, an attacker?

Regardless of whether it is too late for bitcoin itself to make an informed and foresightful choice of using a scripting language versus using enumerated/special cases, I would like to know which would actually be better if only for cases such as "Yet Another AltCoin".

-MarkM-

EDIT: Apparently there *were* some ghastly exploits discovered in Satoshi's script language, so much so that he himself changed it to avoid them; furthermore apparently BIP 17 might actually be undoing one of those changes/fixes...

Coming from cunicula... is this considered irony?

I am civil in conversation with men of quality. However, given the company one typically keeps in the forums, to not be nasty and abusive would reflect poorly on me.

If you're as smart as you say you are, your thoughts, ideas, and logic should speak for itself. Your insults suggest you are either trying to cover up your own idiocy by loudly proclaiming eryone ELSE to be the idiot, or they make you seem like you are abusing the weaker guy who may simply not have as much education or experience as you yet. Either one only makes you sound like a loudmouthed douche who is to be ignored.

Fees are the incentive for running miners after the reward blocks diminish. Keeping the fees under control, while maintaining network security is the goal.

::)

I'll have to remember this one for the next time I want to justify being an ass to someone I consider beneath me.


Back on topic...


I'm curious to know how thoroughly these proposals have been tested. That might go a long way toward swaying opinion. I would imagine having a public alt-coin for the sole purpose of implementing one proposal or the other and seeing how easy it is to break could be a great proving ground.

While practical testing is valuable, it should have no bearing on which BIP is accepted. These BIPs are protocol changes, and providing a stable implementation is the duty of the client, not the protocol. That being said, I'm confident that my bitcoind BIP 17 backports are more likely to hold up to testing, provided the signature check is sane (signing the relevant parts of the transaction), which would actually be a bug in the existing protocol if it weren't.

I'll see if makomk is up to this. His "coiledcoin" post implied he might be.

testing can reveal flaws in the protocol, not just the implementation

this

I have added an edit to the bottom of my previous post... So the "this" referred to has been revised in part in effect...

-MarkM-

Testing is actually one of the reasons I don't like BIP 17; it is harder to test, because it is much easier to steal BIP-17 transactions if the network hasn't yet upgraded (Luke has had to test BIP 17 on the main network instead of testnet because I wrote a BIP-17-stealing robot and ran it on testnet).

I've spent the last couple of days running "transaction fuzzing" tests against both the new BIP 16 code and old clients; so far it has turned up no problems. "Fuzzing" means throwing lots and lots of random inputs at a program and making sure it deals with them properly; it is another good way of finding the "what do you know, we didn't think of that..." bugs.

The fuzzing tool is here:
  https://github.com/gavinandresen/bitcoin-git/tree/fuzzer

Also RE: ghastly exploits:

Satoshi himself made changes to the way the scripting language works after a series of 'ghastly exploits' were discovered back in 2010 after the first slashdotting. I'm so stubbornly against BIP 17 because it basically reverts one of the changes he made (separating execution of scriptSig and scriptPubKey-- take that discussion to another thread in Dev&Tech if you want to argue more about it, please).

Alternatively, testers could just as well run BIP 17 on testnet with an activation date of 0; then they'll reject non-BIP17 blocks. ;)

Just to clarify, BIP 17 does not in any way revert this change. scriptSig and scriptPubKey are still executed separately. There is just a new single value passed from scriptSig to scriptPubKey, just like the stack we already pass.

why is satoshi treated like some supreme being?
"satoshi did that , so he must be right"
"Maybe satoshi thought this so we shouldn't do that"
this is becoming religious

Because he is. http://bitprayer.com/ Praise Satoshi!

It's his project, just because he's not here doesn't mean his friends and coworkers are gonna undo conscious decisions that were made in development. Some of them were made to fix exploits. 

Oh yeah, no. That way of thinking lies ruin and pain, sir.  Having run the ShowEQ project for over a decade (though I haven't really been the active lead developer for years), I learned the hard way that adhering to the original creators intent is not the path to enlightenment.  Only by objectively observing reality and responding to that are you going to develop a better piece of software.  Once you let a piece of software into the wild, you can continue to shepherd it, if you so choose... but it belongs to everyone at that point.

That and I learned social contracts are worth shit when it comes to corporate interests. :)  

This whole thing seems more of a personal attack by Gavin against Tycho than an actual announcement. Almost as though he's trying to manipulate the people away from the biggest pool using propaganda and exaggerations, trying to make Tycho into the scapegoat in case his slapdash change is rejected. Does Gavin feel marginalized or something?

Why couldn't Gavin have just pushed the change through without making this hate topic, see if any of the mining pools rejected it? Ferret out some actual villains instead of baselessly accusing people before the fact.

It's an awful risk I'm taking just asking this, since admins can just ban anyone and delete their posts in order to censor dissenters, but I must voice this lack of confidence in Gavin's leadership.

Satoshi?

   Nothing against the first contributor(s), but it is your project now along with the other developers. Invoking a now 'mythical' persona, tends to cloud the issue. Understandable from a politicians point of view which I guess is a part time role you have been put in. This thread is, in my opinion, doing great good. You have stated your case and appealed to the voters which now include many rather than a few. But bringing up Satoshi's intent with him/them not being present is like bringing up George Washington's intent on how the country should be run.

   I do not understand the full code, so I rely on your explanation and my interpretation of said explanation. BitCoin is a venture that I would like to succeed but not turn out to be just another fiat. My concerns were that power is being grouped into a relatively small group. This issue seems to have been a catalyst that brought it to the forefront.

With that being said, I think it is imperative that the proactive changes for future use of the client first runs through a filter of: "Does this increase or decrease decentralization?" Then run it through other filters as to the security, usefulness, etc...
In this case, there seems to be an impasse on the issue as on how good each protocol will be. I find analogies tend to express the idea of the problem better. Taking into consideration the code, developers, Pool Operators, etc... lets look at it like a Beta vs. VHS problem. Two ideas both valid but an impasse was reached on which one. Developers were held up, suppliers were held up, customers confused, etc... cause no one knew which one would win. It was solved by simple old competition. VHS won. (Shame cause I was for Beta).


Best Regards and good luck.

He was trying to, but I brought it out to public light because of its problems.

Technomage +1   I presume from Babylon 5


Without having read that book the approach seems logical. I have found 'incentives' are a factor of personality. There are 5 types of knowledge in the world. Individual Knowledge, Cultural Knowledge, Spiritual Knowledge, Philosophical Knowledge, and Scientific Knowledge.

Scientific knowledge doesn't/can't state any truism. It states observations from experiments (hopefully repeatable) that gets sent to others to apply Philosophical Knowledge.

But that not being the point, quantifying every individuals 'intentions' would need to asses every individual's application of those 5 types. And with that also being a dynamic not static application of those sets, one could only apply a probability of an individual's intentions.

In short, "Trying to predict human behavior"

I do not know what the intentions of operators are, I only know my own at this point in time. Others might be trying to change BitCoin solely based on Cultural needs, or (heaven forbid) on Spiritual needs.  

I liked your response as it was rational and informative. Mine might not be.

Best Regards.

What problems? BIP17 is your attempt to push through code which has not been proven secure, presumably in order to compromise the integrity of the system. Which government or large banking institution do you work for?

both BIPS are about as secure as a paper safe if not supported properly by the miners

And that's the rub. I feel that his introduction of the additional BIP17 was intended solely to slow progress toward greater security. To what end, I don't know. But having more than one standard is guaranteed to cause a split among miners, which is the security problem you mentioned.

well, that only proves what i have written earlier. the actual implementation, testing and the number of devs who really have looked through the code is what actually counts. that's a prerequisite to being able to fix bugs and enhance it in the future.

Being entirely inconsistent with the Bitcoin design, and breaking it with magical special cases.

Where do you dig up this FUD? BIP 17 is no less secure than BIP 16, and probably more secure in practice.

No, the slowdown you're thinking of is people continuing to push BIP16 even after a better replacement has been proposed.

It becomes inevitable wherever you are involved unfortunately. Your use of weasel words and language tricks give me cause for distrust.

For example, if Gavin were to say (just as an example) "I have never DDoSed anyone in my life", I would take it at face value. However, if you say the same thing, I must spend time figuring out different meanings that the same phrase could have, because you likely mean "I personally have never DDoSed anyone in my life, but I have paid someone else to do it for me" instead.

Sounds like a personal problem.

this wasn't my intention at all
BIP16 is just as bad as 17. (both suggestions have their strong and weak points. you will have to learn how the script works to understand)
nobody ever suggested implementing both. that would be beyond stupid

And, at the same time, there's nothing stopping anyone from implementing both.  It's conceivable someone could create a client that did the validation for both BIP-16 and BIP-17.  Miners could also validate both style transactions.  Since they are both designed to be backward compatible, they will all be recognized as legitimate transactions by the whole network if they get into a block (even if not all clients relay them).  The downside of course is that if you create either a BIP-16 or BIP-17 style transaction and the majority of mining power isn't doing the full validation, you run the risk of losing your coins to theft.

if you implement both - both will have to be supported forever. you wont be able to choose a "winner" in a later stage
implementing both just adds more security risks without any benefits
you would be better off flipping a coin to decide which to use than implementing both

Well if support for one BIP goes down below 50% those coins will become available to redeem for everyone,
at some point all of them will be redeemed rendering a particular BIP obsolete.

Of course the bad thing is that some of those coins will be redeemed by hackers and not by the owners,
but it might happen anyway only if just a single BIP is deployed and support for it goes away.

As I understood BIP16 is currently stronger protected for this kind of situation.

bip16 will require more effort. but not too much.
which doesn't really matters - if either of the BIPs go below 50% support the chainblock is basically doomed.
Also, replace "some" with "most" or "all".
Its a good thing i am not the one who needs to decide which BIP to use - too much responsibility if something goes wrong.
I have already suggested a fight to the death: gavin vs luke, to resolve the issue. There will be a lot of betting going on . good for the bitcoin economy.

and another thing: both BIP will be "invisible" to the user. As a user of bitcoin you wont be able to tell which BIP is used. They do the same thing.

I would like to add something about one of the reasons why I don't want to be the FIRST to adopt P2SH: I don't like doing beta tests in a production environment.

In last 2 days I already got 3 messages from Gavin about new bugs found in his implementation: one "minor bug" and one "major bug" ("one critical line was dropped in a merge and missed in my testing"). Also some coins were possibly destroyed in the process because a bug caused block fees to be lost.

Of course I understand that some bugs are always expected in big projects and Gavin isn't worse at programming than other developers, but that's what happens when such an important change is rushed into production.

Doing exactly as he says.

---

Also, some people are pointing that one/three pool operators can make important decisions/place a veto and this is very bad. But why no one thinks the same about the devs ? There aren't THAT many developers and Gavin can force almost any change he wants by applying some pressure on pool ops. Of course I'm not saying that he wants to destroy Bitcoin, but what if his PC/account/hostages are taken and someone is using his name to push changes ? :)
Not this time, possibly, but that's just an answer to to such accusations.

hm i liked gavins approach of changing things very conservatively. that on the other hand doesnt sound so conservative  :-\


the devs mostly have power since they have much more knowledge about the proposals and the existing code. its hard to do anything about that without many people each spending a big amount of time aquiring that knowledge. the power of the big pools on the other hand is diminished with a few clicks from everybody.

I wouldnt worry about that, not many people update hourly from git source. He will be able to warn the mod's by then that it was hacked.
But it still looks to me that there aren't enough active devs for a project of this scale...
Nobody wants to work for free :)

BIP 16 is not at all conservative. BIP 17, on the other hand, is.

Let's do a brief comparison to disspell any FUD on the matter of even implementation simplicity (protocol simplicity should be obvious from reading the BIPs):

As to the recent major bug in the BIP 16 implementation, it destroys any transaction fees in mined blocks. This is entirely unrelated to BIP 16, but affected because BIP 16 requires a major refactoring of the code. Because BIP 16 requires this refactor to implement in bitcoind, this bug affected all the backports too.

Here's what I've gathered from this thread:


Tycho/Deepbit - concerned about rushing such a big change, concerned about wielding decision power over such a big change

Gavin - concerned about wallet security and allowing bitcoin to move to the next level

Luke - concerned about wallet security and allowing bitcoin to move to the next level


All parties care about having a stable and successful future for bitcoin, and we should not forget that.  I think Tycho/Deepbit's refusal to get behind one of these proposals is quite possibly the wisest move in this whole ordeal and is under appreciated.  What it does is put this incredibly hot bitcoin drama on ice and buys more time for the engineers to debate and the community to form some sort of consensus, which is crucial for something this big.

Slow and steady wins the race (and usually results in it being done right the first time).

All miners have a very strong incentive to do abide by the same rules that the majority abide by…otherwise, they risk their blocks being rejected and their coinbase coins invalid.  I think once it's clear the majority or super majority agree to enforce BIP16/17 transactions, there will be almost zero chance of falling back below 50% support (all miners will make sure they're fully validating p2sh transactions otherwise they could spend a lot of time mining a block that ends up rejected by the network).  

Also, you have to keep in mind that what these BIPs fundamentally do is restrict, not expand, the set of valid transactions.  Hence, even if neither Gavin and Luke-jr yield and they create their own separate forks of bitcoin, miners could simply chose to enforce both styles of P2SH transactions to be safe in knowing that whichever style becomes dominant that they'll never end up on a dead fork of the block chain.  I'm not advocating this mind you, I think it would be better to just pick one (and no matter which is chosen, make sure it's we'll tested before it's rolled out).  But, if it did happen, it wouldn't be the end of bitcoin.

in practice this would be hard if not impossible, the implementation of one bip might mess up something in the other. this will also make future development of bitcoin a lot more complicated
better none than both

Bugs still showing up in BIP 16 sounds like the "deadline" was too rushed. Unless Luke's code is equally well tested and has not been turning out to be buggey we should probably push back the "deadline" to end of next month instead of end of this month?

-MarkM-

BIP 17 doesn't change nearly as much as BIP 16, so it's much easier to audit and test. ;)

Normally, I would agree with this. However, BitCoin isn't dealing within a normal environment. If BTC takes hold, it will need to be as far along as possible because there will be great pressures brought to market. Major industries will either try to co-opt it or destroy it. If anyone has been on the receiving end of Multi-Billion dollar industries ire, they will understand 'all' that will be invoked.

Lets not forget, Gavin was already summoned to the CIA.

Transparency helps because of this.

Tycho, Gavin, Luke, etc... as developers are doing what they believe is correct for them, BitCoin, and possibly other reasons. This protocol change, while important, isn't the concern. The concern is the hold up in development. Since BitCoin is a beta and is already being relied on for Millions of dollars in transactions puts great pressure on correctness. It isn't the developers fault that the community put great faith in a beta, it is not their fault. It is ours for assuming it was a full version with all the bugs worked out.

We can't put the Milk back into the Glass. Development should be transparent and debated among the community. The reasons for this, I believe, are simple. Every major communication company has had to 'make deals' with Governments. AT&T, RIM, Google, etc... and this is just for communication. Now being that BitCoin can be used for 'Communication' and 'Money' transferring; I would not be so naive to believe the project wouldn't be put under great pressure, also.

As to stay on topic: BIP16/17, everyone put their heads together come up with all possible 'bad things' and 'good things', and apply Occam's Razor. And Then, PICK ONE.  Pick a weekend, get together, get drunk and happy(except Luke :) ), and pick one.

I'll shut up as to this matter as I believe my concerns have been conveyed.

Good Luck and Best Wishes.

I'm not really up to anything right now. Coiledcoin's dead (probably together with new altchains in general), and it's not really worth starting anything Bitcoin-based at this point in time.

Layman's question:

Will the proposed new long bitcoin addresses be mandated for everyone going forward, or will the long addresses only be used by people who chose multi-sig?  I definitely share the concern over difficulty in copy-paste, QR codes, eye-scanning etc. due to really long addresses.

What kind of address length are we looking at with each of the proposals?

https://en.bitcoin.it/wiki/BIP_0013 for both
 dont know what exactly the length is going to be

BIP 13 (P2SH address format, used by all BIP 12, 16, and 17) addresses are (almost?) always 34 characters, similar to current addresses. The Address wiki page (https://en.bitcoin.it/wiki/Address) has been ahead of the game for a while now.

I've suggested Coblee to consider BIP17 for Litecoin as an alternative to Bitcoin, let's see if we get anywhere with this.
He might need some help to port and maintain the changes though, if he decides to implement multisig at all.

Why not go a step beyond and make a clean start for the script engine in litecoin?  Make all litecoin transactions be a p2sh style transaction.  And clean up the cruft in the bitcoin script engine.  Make it will tested, etc.

Might be a good idea. I think you can talk to him about it. He said he would have more time soon to work on the client again.

Developers must vote on this, not regular "miners" ( as long developers are trusted)...

I will split my bounty between all developers involved, does not matter of what BIP will be accepted.

If the miners refuse to switch it doesn't work. The devs can't force anything.

But this would pave light way to transition... If transition itself being questionable enough - miners can reject it... Only after this regular users will need to decide.


Small details what matters... People in order of importance

1st - developers
2nd - miners (poolops)
3rd - users

It will eliminate friction from the process...

Really?


Ok,

1st - Developers - lets say 10
2nd- miners - lets say 100
3rd- users - lets say 0


What was that order again?

I'm so sorry for my English...

People in order of importance who can spot problems in Bitcoin development direction...

Sure, everyone is important in different ways.

The 50%+ only applies to miners though, if one dev out of 1000 convinces the miners the change is good it happens. And as long as there are some users who continue using it then the changes protocol continues to exist as a real/used thing.

this is why 1 developer can = 50% of miners :)

+1

Financial software is a different world from most. "If it ain't broke don't fix it" is the rule of the land in that arena, and with very good reason.

Bitcoin is not a multimillion dollar enterprise, yet. In fact, isn't worth much at all if there isn't major development done to improve the network to allow for explosive growth. While I do have a lot to lose if Bitcoin fails, I am not afraid of risk and the rewards are worth the investment. I have a lot of faith in the bitcoin community. Pick a BIP and let's roll.

Sorry, I can't resist to post this...

https://i.imgur.com/LghLs.png

Agree!

I agree that would increese the danger of loosing coins by loosing the keys stored on the 2nd device. One would need to run two programs and some ppl would end up storing both on the same device (if it would be possible to do) negating the security.

I bet most people will use 2-of-3 signatures: One in your PC, one in your phone and a paper backup, kept in a safe or something. If one of the devices get lost or broken, you use the other and the backup to move the funds to a new multisig address. Or you can use 2-of-4 and have two paper backups, one of them to be stored in a new device if one is lost (or using both backups if both devices are broken/lost, which is about the same of having only 2 signatures and a backup of both...).

Fascinating thread.

I'm not a bitcoin developer but I'm a sw developer with some years experience and I found very, very useful this article by genjix:
http://bitcoinmedia.com/the-truth-behind-bip-16-and-17/

By not knowing completely the bitcoin protocol, when I began reading the objections of Luke to Gavin I was unconsciously taking Gavin side because I have a lot of trust in him.
But after studying genhix work (who takes no sides, I think) I'm now leaning towards BIP17: it seems a better choice from a general software good development practice.

+1
I liked the article too, thanks genjix!
Though I've been flipping sides on BIP16 / BIP17 for awhile and still undecided.

did you notice deepbit pool voted with 1 block so far?
http://blockchain.info/p2sh

I missed the info however that he [Tycho] chosed a side in the 16 vs 17 poll.
was this 1 block / vote an accident or just saying "I'm watching you, here's my .5 % of voting capacity"

No, I didn't.
It's a false positive, possibly caused by my node relaying someone else's new block.

I wouldn't choose a side because I don't like both.

Tycho, are you waiting for 50%+ of hashing power to confirm to activate any of the BIPs?

At this moment I decided to start working on implementing BIP16 when 50% of OTHER (not total) miners "vote" for it.
This may be changed if some new scary bugs are found or other important info becomes available.

I don't like the "special case" magic and serialized script form in BIP16, but if most people want it (or lured by Gavin), then I'll let it be.
As I said before, I'm not going to oppose the majority.

I've started a discussion on BIP 16/17 support moving forward (including trying to improve the testing process) here:
  https://bitcointalk.org/index.php?topic=61922.0

(please reply there so the discussion stays mostly in one place)

Newb here:

There's a question that hasn't been answered, afaik: to what extent are BIP16 or BIP17 backward compatibile?

If I have some savings in a paper wallet, will I be able to spend them after the change?

After the change, can I opt out of having to use multiple private key confirmations? Can I use my present wallet on 0.5.2 unhindered?

Can I receive btc from a bip16/17 client on my 0.5.2 client?

Frankly, I think the proposed way of doing things is potentially more trouble than it is worth. With a bit of computer literacy, the present client is plenty secure and reliable.

Thoughts?

BIP16 and BIP17 don't invalidate existing bitcoins.  If you have savings in a wallet, paper or not, you will absolutely be able to spend them.


Absolutely you can choose not to use multiple private keys.  I would think it's something you have to opt in to.

You should be able to use your present wallet but would probably be required to upgrade your client.


I don't think computer literacy is quite the right term - to me, this means familiarity with e-mail and surfing the web, using a word processor and a spreadsheet.  I consider myself a computer expert, and of course I can make do with the current client.  I am sure you are referring to the ability to keep one's computer secure, not just use a spreadsheet, so I'll assume you mean expert.

The problem is that computer expertise is a very high prerequisite to use a currency, and even computer experts get malware and hacked all the time, often without even knowing it.  I think it is a foregone conclusion that we need multisig to counter this.

No, you don't have to upgrade your client to receive coins from somebody using a BIP 16 multisignature wallet.

This thread has been great. It appears that too many are trying to avoid the inevitable - that is, the forking of the bitcoin chain. When there's difference in opinion, well fork that chain please!

Gavin mentioned that the number 1 road block to alternate crypto-currencies being more successful was that of infrastructure (i.e. exchanges, block explorers, etc.).

It's my opinion that we should not be scared of competing currencies (also bitcoin forks) and that we should embrace it and hope for it.
Bitcoin is not just about decentralization, it is also about freedom. If we embrace freedom, this project will excel faster than anyone can imagine IMHO. Many of the fears for going this route stem from selfishness and greed, but also consider that there might be many newcomers to this technology that would not have done so otherwise.

So, the challenge would be to make bitcoin more fork friendly at all levels (exchanges, mining pools, clients, etc). That would be the first great step in Bitcoin's improvement and then all the other potentially great ideas out there would come into these crypto currencies at a much faster pace and I'd bet you would all be more the wealthier. Also, the  BIP 16 vs BIP 17 would quickly become a non-issue in my opionion.

No, a forking of the chain would lead to dilution and confusion and nothing good will come of that.

You never want to hear someone utter "Do you accept my bitcoins?  Oh, no, you accept the OTHER bitcoins?  Dang..."

I understand what you are saying, but a fork in the Bitcoin chain is already in its future.
No matter how much complaining you or anyone else does, it's gonna happen.
My suggestion is that we should embrace it and help it, sure the learning curve on an already very difficult system to understand get a little higher, but the users will manage.

"Do you accept my bitcoins?  Oh, no, you accept the OTHER bitcoins?" and this is a problem because? This is where individuals have the opportunity to influence each other to support the best, most efficient system.

Lots of fear with my suggestion; do you really have a problem empowering people to make a different choice?

Just to be clear; I also have skin in the game. I mining on the bitcoin chain. I buy a few dollars of bitcoins everyday; yet, I'm not scared one bit!

There is a difference in forking the current chain and creating an alt-chain.
In the first case you create confusion and it will only work if everybody migrates to the new fork letting the old one die.
Alt-chains are different in that they have their own blockchain from the beginning and they usually have its own brand.

Uh, no, forks cannot coexist, its either one or the other, and if either of them find out about the other, the shorter fork's transactions/blocks are discarded completely. You might be thinking of alt/scam coins, which can and do coexist, but are not worth any appreciable amount.

EDIT: Beaten by interlagos ;)

"You might be thinking of alt/scam coins, which can and do coexist"
Well, That's not they way I would personally say it, but ok.

Your post and interlagos are simply pointing out some of the technicals and obstacles that must be considered to make a fork possible and coexist - overcoming these are just a small part of what I was implying when I said "make Bitcoin fork friendly". Some things would need to be changed just like things need to be changed to utilize multi-signatures.

BTW, A fork is very similar to an "alt/scam" chain with one key difference: The coin holder before the fork will automatically own the same amount of coins in both chains.

Like I said before, a fork will happen. Don't know when - might be a decade, but it will happen.
Let's embrace and make it Fork friendly.

The intention of my post here in the BIP 16 / BIP 17 thread was to throw out some ideas and hopefully persuade a few bitcoin programmers to take up this crusade. No one interested? OK, moving on.

.......... Back to BIP 16 / BIP 17.
I don't have a problem supporting either one. Please make it happen. If there's a bug or problem down the road.. well, I'm confident it will be dealt with properly.

One could create an alt coin that recognizes the Bitcoin rules and history until a specified time, then the changes activate and the coins part ways. If miners are selfish and split kinda evenly on the issue, they might even be merge mined. You would find yourself owning coins in both chains with the same private key. Hate the new fork? Sell them and reclaim however much value your Bitcoins had prior to the split.

Hopefully such a great schism would attract enough attention from users to prevent anyone from accidentally discarding a key that has coins in the new fork.

Bitcoin is ALREADY fork friendly.

As much as I hate to say it (I'm promoting a fork), Bitcoin is not fork friendly, for the exact reason Gavin said: when you fork, all the coins in existence can be spent twice, one in each leg of the fork, and everyone on the minor leg of the fork is poised to become a victim.  That's a major problem, you simply can't have that.

The only reason I propose that my fork plan has a chance is because I've rigged it so the leg that's destined to be the old (minor) leg has a way to detect spends on the new leg, an idea that I don't think has ever been seriously considered by the developers before.  Were I Gavin, I would want days at a minimum to wait for inspiration on how such a scheme is could fail or be attacked before even considering acknowledging the idea had merit.

Good idea! Should we flip a coin?

This is not so simplistic a matter. There is a major cost to forking (wasted effort on the inferior fork, potential increase in user uncertainty).

Nevertheless, if the benefit associated with picking the best answer instead of the second best answer is sufficiently large, and if there is sufficient uncertainty about which proposal is the best answer, then it will be optimal to fork. Otherwise, it is not optimal.

Here it seems clear that there is major uncertainty about what the best choice is. It is not clear that there are major benefits from making the best choice.

 

You can if you want to, but the client I will use is the one chosen by Gavin and his association of developers.

It's become painfully obvious to me that at least 99% of btc users are not qualified to offer a valuable opinion on BIP16/17. I do however have one piece of advice, it goes something like this:

I work in an industry with high stakes (lives) and fundamentally constant risk management, and there's one simple rule.

Suppose I have to make a decision between option A and B.

A is generally safer but more costly.

B is generally riskier but more efficient.

It's not feasible to always choose A because we'd go bankrupt. We can't always choose B because literally, people would die. We have to weigh the pros and cons and decide. We use knowledge and experience to make that decision. Most of the time the choice is obvious, either A is required because the overall risk factors are high, or B is preferred because all the risks are known, accounted for and considered well within the system's ability to cope.

Sometimes it's not so clear cut. When in doubt, we always choose A.

What does this mean to Gavin, Luke et all? Basically, since there's such a divide between the 2 of you, the safest option should prevail. The integrity and safety of bitcoin must NEVER be compromised. Bitcoin is the world's first and only free (as in liberty) money, for the sake of our futures please do not blow it.

BIP 16 is risky because it modifies a lot of code unrelated to P2SH.

BIP 17 is risky because it exposes part of the current system that we don't currently use regularly.

Neither are perfect. I prefer BIP 17 because it mostly leaves the current system alone, and can't introduce new problems.

thanks for the clarification Luke, it helped me.

You guys are best qualified to evaluate both the size of the risks (i.e. potential extent of the damage) and the probability of them happening. If you can come up with such an evaluation and can get Gavin examine it and give his own eval (if he disagrees with yours) it might be a way forward to solve the dispute. When in doubt, safety first.

Best of luck man!

The safety analogy breaks down because people are dying right now (https://bitcointalk.org/index.php?topic=62402.0) while we debate over which of two airbag systems to install.  And the designers of both systems are in agreement that their own system is better and that the other guy's system is going to maybe cause a disaster in the future.  And everyone else is standing around offering their own opinions of highly variable quality about the good and bad points of both systems, most of which are valid to some extent because neither system is really perfect except maybe in the eyes of the designer.  Meanwhile, people are still dying...

...but if the right decision is made would die less of them.

The way I see it, Gavin's airbag comes with Gavin to support it.  Luke's airbag comes with Luke to support it.  And support is an important part of the equation.

Besides, I believe Gavin has already pretty much decided it's going to be BIP 16 and the vast majority of the community supports that.  So, absent a sudden community revolution, that's what it's going to be, particularly when we get signoff from the biggest pools.  It's not even up in the air anymore.

Gavin seems to be ignoring BIP 17 and forcing everyone to support BIP 16 as much as he can, but he is basically alone in actually opposing BIP 17 (not counting people who oppose both).

I'm not sure how you can say such a thing with a straight face.

In any case, one of the beautiful things about bitcoin is that the only thing stopping you from imposing your will on the people is the will of the people.  Get miners on board with BIP17 and that will be our future.

You should contact the mining pools and convince them of the superiority of your proposal, just the way Gavin did last week. That way all pools will have a chance to evaluate both based on merit.

If you can make a nice business-style Power Point presentation, or maybe a good youtube vid about all the pro's and con's of both proposals (but keep it professional!), maybe you can get them to support your side..?

You could, perhaps, also prepare a pre-compiled client for instant deployment, or maybe a simple step-by-step instruction of how to enable BIP 17 if you run a pool...
.

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). slush was leaning toward supporting BIP 17, but apparently changed his mind after Gavin linked the still incomplete summary of developer positions implying it was an accurate representation.

I was considering making a video series on the proposals in layman's terms, but I simply haven't had time, nor am I really sure how I'd handle making the actual video (I suppose if it wasn't for the time issue, I could get together with someone else local involved in Bitcoin and have them record it...).

I'm not aware of any pool running on pre-compiled binaries, but I'd be glad to provide assistance if any need it.

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?

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

At least pool.itzod.ru (http://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...

Maybe Eligius is anti-furry?

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

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.

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.

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.

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.

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

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 (https://bitcointalk.org/index.php?topic=16385.msg733131#msg733131)

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

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

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.

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.

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

Lol wut

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

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.

If they are 1 confirmation deep, I know I can spend them. In fact I think i can spend them with one no confirmations. Thats not the problem.

Will a second merchant accept those coins in a transaction tho?  I don't think so. Otherwise they would be opening themselves to a double spend attack (which is still unlikely)

i would.

because as you say, an attack is unlikely (far less likely than credit card fraud).

Sorry to be short. The silly part is the cashier waiting for the coins she accidentally charged you incorrectly to get 6 confirms. Obviously no one wants to wait 6 confirms in any situation.

Waiting any confirms at all in any small value situation where you can actually see the person is just rude and unnecessary. If a guy is willing to walk off without paying why both pretending to pay first? To get a 10 or 60 minute head start? Where you going to run after him and try to fight about it? It makes zero difference whether  cops get there 1 hour or 2 hours after the fact to take your report about the stolen groceries.

This is the wrong model.  The problem you mention is even worse today.  Even if you wait the full 6 confirmations, it will still be hours or days faster than waiting for the store and your bank to process a refund to your credit card.  Also, good luck getting cash refunds.  Most places mail you a check when refunding a cash transaction when the amount is over some tiny limit.

Ok, to me this seems like over engineering hell. You are trying to implement a really complex system to solve something you can't solve. Namely the: "guns don't kill people, people kill people" all over again. I humbly suggest the attention be put to scale the bitcoin transaction system instead, security can be handled by external solutions/third parties.

This has been proposed and discussed in depth already. Multisig solves the problem of one hacked device, and multiple hacked devices are much less likely. External security firms add centralization to the system and don't guarantee they won't be A) attacked physically or B) run away with the coins or C) screw up and lose even MORE coins. Even guns have a safety. :)

You have a good point but the point is not entirely accurate. There is a distinction between clients and services, services can handle the security in other ways but clients can't! A good example is the blockchain.info webwallet, which recently added google authentication to their service. With clients it's a totally different story though, you can't add google authenticator to a regular client because there is no service to take care of the support.

That's why it actually does make sense to add protocol level support for multi-device authentication. Then it can be done in a "do it yourself" way, just like Bitcoin is meant to be. This is not just for that though, P2SH will enable escrow features also.

However, your point regarding the complexity is valid, although the protocol level implementation speaks nothing of the complexity for the user. I don't know how much thought the devs have put to how this will actually work from the user's perspective but I hope they have thought about it a lot. I mean, if this is one iota more complex than setting up google auth, then it's a complete waste of time. Only people who don't really need it would use it.

The truth is that the people who are most susceptible to having their computers full of keyloggers most likely have no clue about anything nor will they ever be using so called regular clients. The future of Bitcoin is web wallet services and server based light nodes, only so called nerd power users will be running the original clients. Do they need this? That is the question.

Although I think the problem of security applies to full node clients the same way as it does to server based clients, both could benefit from this a lot if it's made easy. If it's not made easy, all of this work is for nothing. If people want security and convenience they could just use a webwallet service with google auth, problem solved.

So in conclusion I would like to see someone explain to me how does signing transactions from multiple devices actually work, step by step? If this hasn't been thought out in advance, you have to be kidding me.

Step 1, I tell my client to send 5 coins to address XYZ.
Step 2, my client creates that transaction, signs it with the key it has, then sends it to my wallet service.
Step 3, my wallet service looks up my policy preferences, and since the transaction is more than 2 BTC but less than 10 BTC (my policy) it sends a text message to my phone asking me to look up and reply with code Q7.
Step 4, I pull my wallet service card out of my (physical) wallet, go down to row Q and over to column 7, read d013e7 and punch it into my phone.
Step 5, my wallet service verifies my reply, then signs the transaction that I had sent it earlier using the key it has.
Step 6, my wallet service now sends my double-signed 2-of-2 key transaction out to the bitcoin network.
Step 7, the bitcoin network checks that the two signatures on this transaction match the P2SH signature that was provided earlier, and the BTC shows up in the vendor's wallet.

Ok, I understand that a lot of thought has been put into this, but out of experience I can say that when many very complex solutions arise to one problem, it's often the problem that is the problem. There is no transaction system in the world that is secure, it's not mathematically possible. And adding steps to render transactions more secure/cumbersome can be done outside of the bitcoin solution, outside of the computer even, it doesn't need to be integrated into the protocol.

I would still recommend implementing a lighter transaction system that can scale, not a complex one that solves a problem nobody needs solved.

 I am pretty sure you either totally misunderstood what this change is about, or have not thought enough about what requiring two completely separate security keys to sign a transaction could be used for. Think multiple signatures on a check, escrows without requiring a third-party, multi device authentication, etc.

My issue is the 'could' in your first sentence. API's and protocols are about 'should' not 'could'. All of your examples can be solved without it too. Just because you can (could) doesn't mean it's a good idea.

While a service can replicate the functionality that these BIPs provide, a service requires trust .  Requiring a minimal amount of trust is a pretty central component of Bitcoin IMHO

I don't think "could" is being used to signify an optional parameter in this sentence.  What are you trying to say?

When you make protocols/APIs based on "could" you sometimes try to solve everything. I think bitcoin urgently needs a low bandwidth protocol that can scale to millions of transactions per day without needing terrabit internet / petabyte harddrives. Everything else is prio 2, like extensions; which if they are added should not be "hardcoded".

In my 10 year time as programmer I have learned to discern between generic and applied code. Unless the BIP 16/17 application is implemented in a broader generic solution that doesn't make the protocol that much heavier and already has many other vital applications, it should be carefully be considered.

I'm just suggesting the developers focus on the complex and hard to solve core matters, and let the community build the "nice to haves".

The point of BIP 17 is that it is generic...

Ok, nice to hear! So can I use it to sign blocks/coins that where mined with FPGAs in order to create a greencoin branch of bitcoins?

Neither BIP16/BIP17 have anything to do with block construction, blocks are not signed, and coins/transactions are not mined. What you choose to mine your blocks with is your own, but certain alternative chains may be optimized for FPGA's or not. Furthermore, what your greencoin branch of bitcoins do or do not, is up to you.

Yeah, it was more meant as a critique: if the bitcoin protocol was properly designed it would allow for alternate coins WITHIN the protocol to "make inflation possible" EDIT: without needing separate block chains.

Satoshi proposed this shortly before he disappeared. Unfortunately, it never got implemented for Bitcoin (yet). Today, it is alive and well in the form of merged-mining.

Too bad! EDIT: kind of proves my point, we didn't need it in the protocol! ;)

Anyone want to point out to rupy that multisig transactions were already in the protocol, as Satoshi intended, and that BIP16/17 is just a fix to better implement it, because the original setup was so buggy and prone to hacks that it has to be turned off? I don't want to bother.

You kinda did just there, and that also proves my point! :D

hi, I hope Gavin reads these posts! I am just a user but agree with Teramanga on this. There is nothing fundamentally wrong with bitcoin from my viewpoint- it's never been hacked. If wallets need better protection this should be a separate project. I refuse to use a mobile because it is a tagging device, it can and is used by authoritarian  regimes to download all contacts, information and data for further possible use by the state. Many third world countries do not have mobile penetration anyway. How the hell am I going to use separate signatures from one system? I for one will stay with the current version which works fine and hope that deepbit does as well! I do not think this has been thought through and would think the core program will be compromised and accessible and controllable by external authorities. reg.

This isn't about mobile phones.  That is just one example of one possible way to improve security.  There are countless other ways, most of which haven't even been conceived yet.  What they all have in common is that they require a way to divide signing authority so that a single point compromise isn't fatal.

P.S.  If this current single point system works for you, you can keep using it in the future.  It isn't going away.  But lots of people (approximately everyone but you) want the ability to use multisignature systems.

P.P.S.  Loosen your tinfoil cap a bit, and maybe poke some air holes in it.  And I say that as someone that keeps an old Palm Treo working because I don't want Google, Apple or Microsoft to "own" my phone.

This is great news! It's about time.

The new switchover date is the 1st of April so there is plenty of time for miners to upgrade.

To Kjj,   I accept all of your points but as the only one who does not want to change I hope you will accept my right to say that. It does seem that you think multi sig is the way to go and that also reflects gavins point in his original post but in his case I think "everyone  agrees" means the three main developers. Has he asked every one on the bitcoin network (he could there is a way to vote). As a non techie (I know that negates my position) it has been shown that multisig is already in the os program but not used due to bugs. So future development and alternative branches are not ruled out. Also I may seem paranoid to you but I am english and here the police have just trawled millions of phone calls and e-mails stored from the last few years to arrest  Sun journalists for phone hacking. Eventually (my main point) it was yourself who outlined in step by step how a multi sig would work and it looks difficult (to me) and time consuming defeating the speed of current transactions. So please put my mind at rest and do it again for someone like me, an average user who has no mobile, access to only one personal computer and here in the uk internet cafe's are rare and the public library controls access to its database? reg.

to Holiday,  Thanks for that- as the remaining sole user and therefore owner of the bitcoin protocol I would like to thank all the developers and miners  for giving me the tool to retain my intellectual rights over my anonymous bitcoin transactions. Should anyone struggle as I would with the proposed changes as its downward compatible please feel free to rejoin me on BTC v5. reg.

I think that the universe of bitcoin users can be divided into two groups: those that want multisignature capabilities and know it, and those that want it, but don't know it.  I'm pretty sure that you are in the second group, even if you think you are in a third group, those that are aware of multi-sig, and really don't want it.  I really, truly believe that you do want it but don't know that you want it, but it isn't something that I'm willing to argue about.  :)

The example using the mobile phone is pretty common.  I have no idea who first came up with it, but I fleshed it out in detail showing one possible way that it really could work in real life.  But there are other ways to do it.  Most of the other ways to do it haven't even been invented yet, so I have no idea what they will be.

If we want, we can abstract my mobile phone example back a step or two, and come up with something less specific, but still clear (I hope).

Step 1, I tell my client to send 5 coins to address XYZ.
Step 2, my client creates that transaction, signs it with the key it has, then sends it to my wallet service.
Step 3, my wallet service looks up my policy preferences, and since the transaction is more than 2 BTC but less than 10 BTC (my policy), it invokes a verification step.  The verification step involves either me contacting the service, or the service contacting me, using some communication channel other than the one used to communicate the transaction.  This could be a text message on a cell phone, a regular phone call, a personal visit to the local branch office, a telegram, a website, email, a USENET post, snail mail, smoke signals, carrier pigeon, semaphores, chalk marks on mailboxes, etc.  This will be either a little bit slower (SMS) or a lot slower (chalk marks).  You will customize your policy preferences to balance your desires for speed and safety.
Step 4, the communication involves some means of mutual verification, such as challenge-response, code words, photo identification verification, etc.
Step 5, if I am satisfied that I am talking to my service, and they are satisfied that they are talking to me, I can approve or recant the previously sent transaction.  If approved, they countersign using their key.
Step 6, my wallet service now sends my double-signed 2-of-2 key transaction out to the bitcoin network.
Step 7, the bitcoin network checks that the two signatures on this transaction match the P2SH signature that was provided earlier, and the BTC shows up in the vendor's wallet.

This is a basic model that has already been invented, and in the abstract sense is actively used all around the world every day.  The specifics can be adapted in many ways to meet different needs while still keeping some essential features and characteristics.  Other models may also work that accomplish the same goals.

And I want to stress two important things that I think are easy to overlook in this discussion.

First, no one can force you to use multisignature systems.  Even if there was a proposal to modify the network to totally disallow single signature transactions (a change which would be approved by pretty much no one at all), it would be trivial to be your own verification service.  Your computer would run bitcoin, and also run a second program just to approve them.  This could either be automatic or manual.  If automatic, it would be exactly the same as what everyone is using now, as far as they are concerned.

And second, bip16/bip17 are totally not about whether multi-sig is good or not, or will be included or not.  They are about how multi-sig will work behind the scenes.

to kjj, thank you for your well thought out reply and constructive comments. I also do not wish to argue about this just understand it. I agree with you and probably almost everyone else that a more secure wallet is desirable (even necessary) to get BTC a bit further towards acceptance. But wallets/exchanges are where the hacks occur not in the core protocol. All the measures you outline in the second verification process mirror the existing fiat currency verification procedures and would (in my opinion) be accessible and controllable by those authorities. I know my usage of BTC at the moment is probably horrifying to any computer literate person from the security aspect. But it is probably replicated thousands of times across the network. If I show you what I feel is the only practical way for me to operate maybe you can appreciate my difficulty in moving to a (proposed)system that needs as yet un-invented solutions to work.
I have downloaded BTC v5 on my computer. I can buy with fiat on intersango BTC and transfer anonymously to GLBSE to purchace dividend paying shares. I can do the reverse and my only interface (regrettably) is between the bank and and the exchange. I do download my wallet.dat to a usb (unplugged mostly) and that is it!. I know I may already have compromised my wallet by having key loggers to log my pass phrase but what can I do ? I am not able to download a new windows xp version and work offline to use my pass phrase! If I use an online wallet service I have just doubled my exposure and risk. I have a landline telephone but that is tapped by MI5. I suppose I could use a public telephone but here in the uk when I asked where the nearest one was everyone said why not use your mobile and did not even know where they were. At the moment it would be very complicated and time consuming to adopt a second sig aproach for me. reg

Jeez, then just don't use it. What was your point again?

Another example of how it could be used:
You create a 2-of-3 signature for your wallet. One you stick in your safe, one you keep on your USB key, and one you send to an online anonymous wallet service. Using the combination of USB key with a simple app, and the online wallet service, you can send bitcoin from any computer. The online service can't spend your bitcoin without your permission, since it requires both of you to sign a transaction. The computer you plug the USB key into can't spend your bitcoin no matter how many viruses and key loggers are on it, since it still needs the online service to sign any transactions you sign. And if the anonymous service does a MyBitcoin and dissapears, since your key is 2-of-3, you can go to your safe, grab the third key, and use your USB key and safe key to get your bitcoin out. This is something you can even run through Tor anonymizer, since you don't have to trust the wallet service.

But it doesn't have to be that way.  The service doesn't have the ability to spend your money, and if you set things up right, they can't prevent you from spending it either.

Think of a script in a transaction that can be redeemed either with Key C, or with the pair (Key A + Key B).  This is usually called "(A and B) or C".

You generate a bunch of these offline.  Key C is protected somehow and is never in a computer connected to a network, like printed on paper and stuffed in a safe.  Key B goes to the service (or comes from the service, either way).  Key A goes in your wallet.dat.

So, if someone breaks your computer and gets Key A, they can only spend small amounts, depending on the policy you've established with the service, and only until you realize that someone else has your keys and you tell the service to not sign anything any more.

If someone breaks the service and gets Key B, or if the service isn't trustworthy, or if the service is coerced by the government, they can't spend your money because Key B isn't sufficient.  They can stop you from spending it, at least until you go to your safe and fetch Key C, but that would instantly show that they have been compromised.

Herbert,   I do not intend to at the moment but it was not clear at first I had that choice and my point was/is, of course I would like better wallet/exchange security, but nothing I have heard proposed either does that relatively easily and improves what we have. I am just too old to get a degree in computer sciences to run a secure system! reg.  edit: Rassas proposal deserves a look at was posted whilst I was eating thanks for that info rassa. reg

They are explaining how the new feature will work. You do not need to use the new feature. Your user experience with the system will remain unchanged, unless you wish to use the new feature.

to Rassa. read your outline again and it sounds really possible and has allayed my concern that whatever is eventually applied to the core program  I can stay anonymous and better protected .  Does not that require two out of three key system though. I think it could still be done with something like kjj suggested but without the extra key option. I will wait on the side lines in anticipation but hope you are not too upset that I do not even know what a "simple app" is or how to apply it. I hope someone will come up with a cunning plan when the dust has settled. thanks for your explanations .I feel somewhat relieved that there is light at the end of the tunnel. regards reg.

Kjj posted pretty much what I said, except the key I said to pot in the safe would still require the one on your USB key, while in his example the safe key is all you'd need (his is better). This is something that requires a protocol change and can't be done with software.
Regarding a "simple app," it can just be a small program on your USB key that you can run without needing to install it. It only needs to do two things, communicate with the online wallet, and sign cryptographic transactions. You come to any computer, plug in the key, go to the online wallet, send money to whatever address you want, then run the app on your USB key and sign it to verify it.
Currently your only option is to store a copy of the private key in the online wallet and in your safe. Although that will protect you if the online service dissapears (you still have the key to your money), if the online service gets hacked, the hackers can take all your money.

to rassa. thanks rassa that sounds the best way as kjj outlined and I guess that would be available if the protocol is imported. From my point of view it only adds one additional step in running the app between sending the transaction and it actually being sent. So the small additional time taken and not having to access another device is worth the increased wallet security. By not access another device I know you would of course need to introduce a usb or similar storage medium but the fact kjj said that could be loaded offline  appeals to me and not having to use a mobile or use an online wallet service would be preferable. So in laymans terms what I am doing is sending BTC and then asking myself to verify the transaction by a key only I know (because it was produced offline and is only on the usb say) before the BTC is transmitted (irreversibly) to the receiver. Is that about it? reg.

I'm convinced. Linode robbery could have been avoided if multisig where at work.

http://www.youtube.com/watch?v=vjaqM4yd_RA

I apologize to Gavin for picking up on him regarding multisig txs. Hope he finds the best solution to make it real for all of us reaching to an agreement with Luke and the community.

Maybe not a good place for this, but I want assign some coins to the chain which can only be spent if N out of M private keys sign the transaction.

What's the best way to do this?   Thanks :)

Right now, I think you'd need to write the script by hand and probably mine it yourself too.