Old P2SH debate thread

[paraipan]

I trust no one that's why i use bitcoin when trading with you people so let's try keeping the trust factor aside a moment when serious protocol changes are involved.

At this moment i am really pleased and happy with the way bitcoin works as a protocol and at the user interface but it seems that, according to many, i am a big geek for being able to use it as such. Even my parents understood how to use it the first day with no problems.

I like Gavin's and team efforts to improve and make the life easier for the not-so-techie people in every aspect but not on this one. We started with OP_EVAL and it didn't work so good and now Gavin's proposes another method, better in theory, with a short BIP and a shorter deadline ahead. Some voices start to raise and Gavin states he's almost out of patience. This doesn't sound right to me.
Until now the one who has the most convincing arguments is Luke-jr. He states that, and i agree with, the power must remain with the miners, between others.

So please, bitcoin developers, don't ruin this trying to make it better. If we can't agree on something like this maybe isn't the time to do it and you can leave the people adapt by themselves like they did for over 3 years. I don't want bitcoin adapted for large corporations or complicated centralized services. You already gave us the encrypted wallets so, if you ask me, the people that can't guard their money don't deserve to have them.

I don't code or read code either only a small miner, investing time and resources into this project and be happy with what i get. The thing that gives value to bitcoin is all of you out there doing same. Thank you

[1714809315]

1714809315

[1714809315]

1714809315

[1714809315]

1714809315

[casascius]

Until now the one who has the most convincing arguments is Luke-jr. He states that, and i agree with, the power must remain with the miners, between others.

So please, bitcoin developers, don't ruin this trying to make it better.

...

I don't code or read code either only a small miner, ...

Wouldn't this be like a driver who has never worked on an engine let alone designed one, trying to tell a bunch of engineers that one of them is the most convincing not because of the merits of his design, but because he argues that the control over the engine design must remain with the drivers, not the engineers?

I think when Gavin says he is out of patience, he means he needs a beer, and not because he needs to release some untested code ASAP.

[paraipan]

Until now the one who has the most convincing arguments is Luke-jr. He states that, and i agree with, the power must remain with the miners, between others.

So please, bitcoin developers, don't ruin this trying to make it better.

...

I don't code or read code either only a small miner, ...

Wouldn't this be like a driver who has never worked on an engine let alone designed one, trying to tell a bunch of engineers that one of them is the most convincing not because of the merits of his design, but because he argues that the control over the engine design must remain with the drivers, not the engineers?

I think when Gavin says he is out of patience, he means he needs a beer because someone, who is referred to elsewhere as "lord asshat" on the board, is being an asshat?  And not because he needs to release some untested code ASAP.

sort of... the fact is the engineers always design or improve their product according to the users feedback, if i'm not mistaken, like you did with your coins 

[casascius]

sort of... the fact is the engineers always design or improve their product according to the users feedback, if i'm not mistaken, like you did with your coins  

Absolutely, it's the drivers who ultimately decide whether to buy the car.

In this case, Bitcoin is like a car that is easily stolen.  That might work for you, but is preventing a lot of other people being interested in it.  Not very many people can effectively ensure malware won't get on their system.  So the feedback of "don't worry about me, I keep my car in a garage at all times, at home and everywhere else I go" isn't feedback that's going to increase mass appeal.

In addition, Luke is the kind of person who would design your next car to be steered with your feet and accelerated with your hands, just like airplanes are taxied, and he would argue that this is easier and safer for everybody because pilots won't have to switch between two ways to drive a vehicle when it is on the ground.  (Simply do a search for "tonal bitcoin" for a prime example)

[Luke-Jr]

(1) slow initial block chain download.

Fixed in 0.5.2 (at least in some/many cases).

(2) UI deficiencies (please put in a "Rescan" button somewhere. Non-technical users can't be reasonably expected to user the --rescan parameter).

It's -rescan. It's also never needed in theory...

(3) lack of wallet security (wallet encryption isn't offered by default, why?).

Wallet encryption is mostly a PR stunt. In the end, you still can't back up the "encrypted" wallet as-is without losing privacy, and a trojan can just wait until you unlock your wallet.

(4) no automatic wallet backups by the client (understandable in the light of (3) as unencrypted wallets should never be automatically backed up).

This is the one biggest problem with Bitcoin-Qt right now IMO. I don't see any reason the AES code can't be recycled to encrypt the whole file when backing up.

That being said, these are all off-topic here... Can a mod split it off (ideally in the Dev forum)?

[jake262144]

It's -rescan. It's also never needed in theory...

Funny you should say that. DeathAndTaxes and I were helping a guy just last night and -rescan fixed his problem (https://bitcointalk.org/index.php?topic=58610).

Wallet encryption is mostly a PR stunt. In the end, you still can't back up the "encrypted" wallet as-is without losing privacy, and a trojan can just wait until you unlock your wallet.

Naturally if your machine is crawling with malware you've already lost the war. Only multi factor authentication (multi-sig) can help you.
That being said, encryption by default is VERY useful because an encrypted wallet can be much more safely propagated defending it against data loss, eg. it can be uploaded to the internet and the attackers won't be able to breach it provided the passphrase is half-decent.

This is the one biggest problem with Bitcoin-Qt right now IMO. I don't see any reason the AES code can't be recycled to encrypt the whole file when backing up.

A great idea but the user needs to have encrypted the wallet in the first place for that to work. We don't want to rely on some hard-coded default encryption passphrase now, do we?


I only posted this here because the discussion had already watered down but you are 100% correct Luke.
I request the Mods kindly split this subdiscussion into a new topic, please.

[paraipan]

sort of... the fact is the engineers always design or improve their product according to the users feedback, if i'm not mistaken, like you did with your coins  

Absolutely, it's the drivers who ultimately decide whether to buy the car.

In this case, Bitcoin is like a car that is easily stolen.  That might work for you, but is preventing a lot of other people being interested in it.  Not very many people can effectively ensure malware won't get on their system.  So the feedback of "don't worry about me, I keep my car in a garage at all times, at home and everywhere else I go" isn't feedback that's going to increase mass appeal.

In addition, Luke is the kind of person who would design your next car to be steered with your feet and accelerated with your hands, just like airplanes are taxied, and he would argue that this is easier and safer for everybody because pilots won't have to switch between two ways to drive a vehicle when it is on the ground.  (Simply do a search for "tonal bitcoin" for a prime example)

What car is not easily stolen ? You can insure it if you want but the engineers can do very little about it by putting alarms or hard to copy keys in it. Overprotecting users won't do any good to increase adoption. Educating them how to drive the damn thing maybe.

Btw i try not to comment on people i don't personally know.

[casascius]

What car is not easily stolen ? You can insure it if you want but the engineers can do very little about it by putting alarms or hard to copy keys in it. Overprotecting users won't do any good to increase adoption. Educating them how to drive the damn thing maybe.

How do you educate everyone to never get malware?  Have them stay off the internet?  There is simply no other way...

For me to practice safe bitcoin, I essentially dedicate a computer to it.  It is convenient that I own spare equipment that can be used for this purpose.  Most users do not.

I don't know of any car that can be remotely stolen where *poof* it just disappears off the owner's driveway, completely untraceably and anonymously, just because (for example) the owner had the misfortune of driving within range of a bad guy's WiFi hotspot on the way home, something he could not have foreseen nor avoided nor knew ever happened.  But that's essentially how bitcoins are right now.  Any of these proposals, if adopted, will give the average user a serious and easily-understood way to prevent this from happening to their bitcoins - I appreciate that most everybody sees that.

[paraipan]

What car is not easily stolen ? You can insure it if you want but the engineers can do very little about it by putting alarms or hard to copy keys in it. Overprotecting users won't do any good to increase adoption. Educating them how to drive the damn thing maybe.

How do you educate everyone to never get malware?  Have them stay off the internet?

I don't know of any car that can be remotely stolen where *poof* it just disappears off the owner's driveway, completely untraceably and anonymously, just because (for example) the owner had the misfortune of driving within range of a bad guy's WiFi hotspot on the way home, something he could not have foreseen nor avoided nor knew ever happened.  But that's essentially how bitcoins are right now.

now i agree with you, so bitcoins are not cars. I only hope the dev's implement good and tested security measures in the protocol.

[runeks]

In this case, Bitcoin is like a car that is easily stolen.  That might work for you, but is preventing a lot of other people being interested in it.  Not very many people can effectively ensure malware won't get on their system.  So the feedback of "don't worry about me, I keep my car in a garage at all times, at home and everywhere else I go" isn't feedback that's going to increase mass appeal.

In my opinion, rushing things has the potential of causing far more harm than individuals getting their wallets stolen. Introducing a serious security vulnerability into core Bitcoin is incomparably worse than individuals getting their wallets stolen.

I have great respect for both Gavin and all the other developers who devote much of their time to improve Bitcoin. It is greatly appreciated. But I honestly think that we're far better off with Bitcoin developing slowly and steadily. There is no rush. There is no deadline to reach. If developing a secure implementation of multi-signature authentication takes 12 months, the wider adoption of bitcoin might very well be postponed 12 months. But if an insecure implementation opens a hole in core Bitcoin, we have destroyed much of the trust that has been built up around Bitcoin so far. It will not be impossible to restore, but I think we can expect that if this happens, every time Bitcoin is mentioned, a side remark of the serious incidence will be added. And justifiably so.
In my view, we have plenty of time for Bitcoin to slowly evolve into a secure and widely adopted technology. Not rushing can only postpone this, rushing it might do irreparable damage.

From reading Gavin's posts I understand that these kinds of issues arise out of a disconnect in the development of Bitcoin: many features to implement with a very high standard of security and few people to actually implement them and audit them. It seems we are better off solving this fundamental issue, rather than hurrying protocol changes through, in order to attract new users.
I imagine that a sort of Bitcoin Foundation be set up, where large corporate actors (with money) from the Bitcoin scene can buy a seat on the board of this foundation. They each buy a vote with their seat. The money is used to fund developers and, perhaps most importantly, security advisers, that can bring to the Bitcoin development process the level of familiarity with software security that is necessary. Their seat on the board gives them a vote in decidingo what their yearly donation, or at least a part of it, is used for in promoting the development of Bitcoin. I see it working in many ways similar to projects like Linaro and the Khronos Group. They are not-for-profit organizations that bring together competitors in an industry, through the common goal of improving the software that they all rely on.
I'm not sure if there is actually enough capital available in the Bitcoin economy for this to work at the moment, but I think this is needed for Bitcoin to keep evolving in a secure and stable manner.

[notme]

Why not allow all the implementations to coexist for a while?  Different miners/pools can support whatever implementations they want.  When we are ready to transition to the proven method, we vote against the other methods by requiring a higher fee for those types of transactions, or not mining them at all.  Basically, I think we should let the market decide.  If one method bloats the chain, require higher fees.  If one method introduces a security issue, exclude it.

[kjj]

Why not allow all the implementations to coexist for a while?  Different miners/pools can support whatever implementations they want.  When we are ready to transition to the proven method, we vote against the other methods by requiring a higher fee for those types of transactions, or not mining them at all.  Basically, I think we should let the market decide.  If one method bloats the chain, require higher fees.  If one method introduces a security issue, exclude it.

Because...

In this case, Bitcoin is like a car that is easily stolen.  That might work for you, but is preventing a lot of other people being interested in it.  Not very many people can effectively ensure malware won't get on their system.  So the feedback of "don't worry about me, I keep my car in a garage at all times, at home and everywhere else I go" isn't feedback that's going to increase mass appeal.

In my opinion, rushing things has the potential of causing far more harm than individuals getting their wallets stolen. Introducing a serious security vulnerability into core Bitcoin is incomparably worse than individuals getting their wallets stolen.

[notme]

Why?  As long as the implementations are run on machines with no private keys they can't break anything.  The main client can take a conservative approach, and additional implementations can be used by other miners/pool operators.  If a pool op introduces a flaw, he's only at risk if he doesn't take precautions to isolate the pool server from private key storage.  Software monoculture is why we have such a shitty security environment to work in.  We need diverse methodology so the entire network doesn't all break at once.

[ripper234]

Can anyone provide a TL;DR? Haven't read the above thread, if it's there already just tell me.

You can also answer on Stack Exchange

[notme]

Why?  As long as the implementations are run on machines with no private keys they can't break anything. 

How thorough of a test would that actually be though?

Unless one is needed for the coinbase transaction (I'm unclear on that), mining requires no private keys, only public keys to pay to.  So, it could be anything from a few small miners to an entire pool op taking it live after he's comfortable with small scale tests.  If a private key is required (I'm not sure what for), it could be swept to a different address anytime it received funds.

[Matthew N. Wright]

TL;DR?

Bitcoins are growing up, people are making decisions that they need to make, while others are biting their nails.

For security purposes, bitcoin wallets need 2 keys-- at least-- and that point remains unargued.

How it would be effective for escrow however is beyond me considering that it wouldn't do anything other than provide a false sense of security, unless of course you made it 20 keys and trusted the opinions of all of those people (who knows, maybe that's the future of the internet? )

Bottom line, Gavin is kind of a project leader, and as a fellow project leader I understand him when he makes a decision based on an interest in providing an actual result. Bureaucracy slows things down. Luke Jr is a also a project leader who doesn't want bitcoin development decisions being rushed into. I understand him when he brings these issues to the public as they are quite serious. Everything development related reflects on the entire bitcoin community.

So here's my two cents-- Gavin, at the risk of 'wasting your time', can't you have two separate developments going on and test them both for functionality? Isn't that what a project leader is supposed to do? Luke? Can't you just start working on the direction you'd like to go and present it in a way that could be agreed with?

You know, not everyone here on these forums is a bitcoind code wrangler, but that doesn't mean we couldn't all learn. Situations like these make me think I should get involved myself.

[theymos]

Why not allow all the implementations to coexist for a while?  Different miners/pools can support whatever implementations they want.  When we are ready to transition to the proven method, we vote against the other methods by requiring a higher fee for those types of transactions, or not mining them at all.  Basically, I think we should let the market decide.  If one method bloats the chain, require higher fees.  If one method introduces a security issue, exclude it.

You don't understand the proposals. Anyone "testing it out" risks ending up on a separate network.

[notme]

Why not allow all the implementations to coexist for a while?  Different miners/pools can support whatever implementations they want.  When we are ready to transition to the proven method, we vote against the other methods by requiring a higher fee for those types of transactions, or not mining them at all.  Basically, I think we should let the market decide.  If one method bloats the chain, require higher fees.  If one method introduces a security issue, exclude it.

You don't understand the proposal. Anyone "testing it out" risks ending up on a separate network.

You are correct.  I'm tired and you're right.  Each implementation would be required to perform all the validations.  Since validations are pretty much all we're doing here, it's an everyone or no one scenario, not a buffet.  Sorry for the derailment.

[runeks]

Bitcoin used to validate scripts that way, but ArtForz discovered a bug in July of 2010 (the OP_RETURN bug) that allowed anybody to spend anybody else's bitcoins.  It by far Bitcoin's biggest bug and Satoshi's biggest brain-fart.

Part of the fix was to make executing the scriptSig completely independent of executing the scriptPubKey (see commit 7f7f07 in the tree if you're really interested).

Can anyone provide links to anything that has details on this incident? I've tried searching without luck.

[interlagos]

I originally voted for Luke's CODEHASHCHECK proposal because it sounded more elegant and because I fully support the idea of bitcoin becoming more democratic. However I liked the analogy of P2SH like being a preprocessor to C++ in this post by Stefan Thomas: https://bitcointalk.org/index.php?topic=56969.msg691560#msg691560 so I might consider voting for P2SH as well. Of course one might argue that bitcoin protocol should not evolve as C++ but that's another story.

Anyway my point is that we should consider worst cases more carefully compared to what particular approach enables.
There must be a step-by-step plan of what might go wrong and what our actions should be.

By the way last time I checked P2Pool was third in hashrate distribution (after DeepBit and BTCGuild) so convincing a few pool owners might still work for some time, but in a long run individual miners should be involved in decision making and everybody should understand the pros and cons of a particular approach.