Topic: Old P2SH debate thread - page 5. (Read 19705 times)

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

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.

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.

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

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.

Because...

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.

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.

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.

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.

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.

Funny you should say that. DeathAndTaxes and I were helping a guy just last night and -rescan fixed his problem (https://bitcointalksearch.org/topic/block-explorer-bitcoin-client-btc-amount-discrepancy-58610).

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.

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.

Fixed in 0.5.2 (at least in some/many cases).
It's -rescan. It's also never needed in theory...
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.
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)?

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)

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 

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.

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

Mike, it's still going to be a cat and mouse game, as all security is.
Of course, raising the bar is always desirable. Common multi-sig deployment will render the old attack vectors ineffective.
However, we can rest assured that the bad guys will bring themselves up to speed and keep mounting increasingly complex attacks.

I do believe, however, that it's not inadequate security that's hampering wide-scale Bitcoin adoption but excessive technical issues with the client:
(1) slow initial block chain download.
(2) UI deficiencies (please put in a "Rescan" button somewhere. Non-technical users can't be reasonably expected to user the --rescan parameter).
(3) lack of wallet security (wallet encryption isn't offered by default, why?).
(4) no automatic wallet backups by the client (understandable in the light of (3) as unencrypted wallets should never be automatically backed up).

I'm sad to say these relatively MINOR issues do seem to have a heavy negative impact on the overall impression of the client.

Being active on the Newbies and Support subforums, I hear those issues being raised time and time again by very non-technical users who install the client and expect everything to just work.
They hear about the bitcoin PROTOCOL being secure and confuse that with client-side security (data theft/loss).

I'm writing this here hoping to raise these issues with the core developers.
Very little work put into purely cosmetic issues can make a lot of positive impact.

Ok, since none of the options are perfect, how about we try to satisfy everyone with a hybrid solution?

How about we just redefine OP_NOP1 to mean "do nothing right now, but if the rest of this script is valid in the normal sense, then unpack the second script and run it too".  It'll break old clients, and we have to deal with that, but this way we don't have a special case second code path.  Essentially do exactly what P2SH does, but make the recognition explicit with a dedicated opcode, and not implicit.  Make it a flag that can only be set by the OP_P2SH opcode and can't be cleared, maybe even make the new opcode trigger an immediate validation failure if found by the second pass interpreter so that people can't try to sneak recursion in with it.

So, the default P2SH scriptPubKey would become:

Revised protocol draft, without stack abuse: https://github.com/luke-jr/bitcoin/commit/f026234cf4edc53de4d9e60ccea581adbcb8ee3c