A startling thought crossed my mind

[SgtSpike]

1st: this means that all merchants and users need to be downloading the blockchain which I thought there was a consensus that eventually this isn't going to be possible anymore which again leads to centralization..

2nd: wouldn't this mean that when either BIP12, 16 or 17 get rolled out those clients that wont update will essentially ignore the new transactions so Gavin has to get the support from every single user, not just the majority of the miners in order to successfully implement that change?

There's a lot of ways to get around not downloading the full blockchain.  Technically, you could just hold the last 2 blocks, then use those to verify future transactions.  As long as you start with a valid block from a trusted source, the future blocks cannot be calculated wrongly.  The next block's hash is created in part from the hash of the prior block, which is why it is a chain.  So if the prior block is valid, and the next block follows all of the rules that are set in the client, that is all that is needed to verify that a block is legitimate.

As far as gathering current balances for Bitcoin addresses without downloading a full blockchain, well, that's a bit of a different challenge.

I can't speak for the potential BIP changes, only that I know Gavin said it would be compatible with existing clients.

[1714027464]

1714027464

[1714027464]

1714027464

[1714027464]

1714027464

[FreeMoney]

1st: this means that all merchants and users need to be downloading the blockchain which I thought there was a consensus that eventually this isn't going to be possible anymore which again leads to centralization..

2nd: wouldn't this mean that when either BIP12, 16 or 17 get rolled out those clients that wont update will essentially ignore the new transactions so Gavin has to get the support from every single user, not just the majority of the miners in order to successfully implement that change?

It would be sufficient to get all headers and then fill in with only the full blocks that you actually need. The implementation might be a little bit complicated, but you won't have to trust your source still, you'll be able to check that the block has the required header, and so know that it fits. (I'm not 100% on this actually, someone please confirm.)

My understanding is that those BIPs can lead to miners accidentally making blocks that won't be accepted. Users don't need to get a new version.

[hazek]

My understanding is that those BIPs can lead to miners accidentally making blocks that won't be accepted. Users don't need to get a new version.

Even once multisig transactions are getting put into blocks??? I'm confused because you are sorta telling me it goes both ways, users can reject blocks found under invalid rules but they also wont reject blocks with multisig transactions even if they aren't updated..

[BadBear]

My understanding is that those BIPs can lead to miners accidentally making blocks that won't be accepted. Users don't need to get a new version.

Even once multisig transactions are getting put into blocks??? I'm confused because you are sorta telling me it goes both ways, users can reject blocks found under invalid rules but they also wont reject blocks with multisig transactions even if they aren't updated..

It's called backwards compatibility.

[FreeMoney]

My understanding is that those BIPs can lead to miners accidentally making blocks that won't be accepted. Users don't need to get a new version.

Even once multisig transactions are getting put into blocks??? I'm confused because you are sorta telling me it goes both ways, users can reject blocks found under invalid rules but they also wont reject blocks with multisig transactions even if they aren't updated..

I'm totally getting out of my depth here, but I think it's all good because multi-sig has been built in all along. Your client might not be able to fully understand the requirements to spend those tx, but it doesn't matter, it can see that the inputs are greater than or equal to outputs.

edit: now I'm getting lost, won't users need to know if the right criteria has been met in order to tell if that tx can be a valid input in a later tx?

Bitcoin? How does it work?

[hazek]

I did a quick search for backwards compatibility and I didn't find an explanation, so I'd second FreeMoney.

[SgtSpike]

Picked out some interesting things that Gavin and theymos have said regarding the matter...

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

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

Miners (as a group) should not be given any say over issues like this. They do not necessarily know what the best option is. The issue should be decided by people very familiar with the protocol and the proposals.

I suggest that we compile a list of everyone who knows a lot about the Bitcoin protocol, invite them to a two-week discussion via email, and have those who participate in the discussion vote on the issue at the end of the two weeks. If one proposal gets enough votes (two-thirds, say), then Bitcoin clients will be programmed to apply the new restrictions ~3 months in the future. Miners will have to upgrade by then or their blocks will not be recognized by most clients. If there aren't enough votes for any proposal to pass, the issue will be shelved for a while.

[BadBear]

https://bitcointalk.org/index.php?topic=61125.msg726268#msg726268
https://bitcointalk.org/index.php?topic=60950.msg711055#msg711055
https://bitcointalk.org/index.php?topic=60433.msg709359#msg709359

That's what I found looking real quick.

There is a lot of good information around here and all your points have been hashed(puns!) to death (or are just erroneous assumptions).

[Gavin Andresen]

RE: lightweight versus heavyweight clients:

First: lightweight clients (like Multibit) that don't store the entire blockchain must rely on the rest of the network to confirm that transactions are valid.  They can't check for themselves (this is true today, and BIP 16 doesn't change that at all).

Full clients do check, but it is still not safe for them to accept 0- or 1-confirmation transactions; an attacker might be sending them an attempted double-spend (and the network might be still be trying to figure out which 'side' of the double-spend will win).  That is also true today.

"Backwards compatibility" means that all valid transactions created by the new software will be accepted as valid transactions by the old software.

But, after BIP 16 is supported by a majority of the network, there could exist transactions that the old software considers valid but the new software rejects as invalid.

So... does BIP 16 make things riskier for people running old software?  Yes, a tiny bit, in the very particular case of 1-confirmation transactions. And that particular attack requires that the attacker manage to mine a block that they know will be found invalid (which is expensive). Again, if you get bitcoins from somebody you do not trust then you should wait until they have 3 or more (6 if you want to be extremely safe) confirmations before considering the payment final.

If you want all the technical details of why BIP 16 does NOT increase the risk for 0-confirmation transactions but does for 1-confirmation transactions... ask me another day (it has to do with how the old software recognizes "Standard" transactions and won't even show you transactions it doesn't recognize).

[hazek]

Ok.

I can't for the life me then understand why you need the majority to support your BIP16 before your role it out? Couldn't you just role it out and let a small minority start using it and see where that takes us? (I know you answered this somewhere before, but I can't remember where exactly it was)

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 judge whether or not more than 50% of hashing power supports this BIP, miners are asked to upgrade their software and put the string "/P2SH/" in the input of the coinbase transaction for blocks that they create.

On February 1, 2012, the block-chain will be examined to determine the number of blocks supporting pay-to-script-hash for the previous 7 days. If 550 or more contain "/P2SH/" in their coinbase, then all blocks with timestamps after 15 Feb 2012, 00:00:00 GMT shall have their pay-to-script-hash transactions fully validated. Approximately 1,000 blocks are created in a week; 550 should, therefore, be approximately 55% of the network supporting the new feature.

If a majority of hashing power does not support the new validation rules, then rollout will be postponed (or rejected if it becomes clear that a majority will never be achieved).

So the only reason for the vote is to gauge whether or not the proposal would eventually achieve majority? If I understood this correctly, maybe you should have stressed that point more.

[Costia]

If clients use bip16/17 before 51% of the miners support it, invalid P2SH transactions can end up in the chain, because old miners will think they are valid.
when 51% of the miners upgrade invalid p2sh transactions will be rejected by minersand will never end up in the block chain- so even if an old client thinks it's valid - it doesnt matter , because there wont be any invalid transactions in the blockchain

[jancsika]

Depending on what rule changes you are talking about it doesn't matter if 95% of miners choose to switch to say 50BTC reward forever. The power is with the merchants to reject the false coins.

Please explain to me how they can do that?

They just keep running the code they've been running.   It will reject the 'bad' blockchain being produced by 95% of the miners, and accept the 'good' chain being produced by the other 5%.

Uh-oh, our public, decentralized p2p ledger that bases official history off the total difficulty of computing the ledger has been infiltrated by Ceylons!

No worries, we'll just fight the Ceylons' superior computing power by refusing to upgrade to their new client, and just keep using the old client.

Which is an implementation of the Bitcoin protocol.

Which bases official history off the total difficulty of computing the ledger.

Which is desirable because it solves the problem of having to trust...

...hm, I can't remember.  Gavin-- remind me what problem the Bitcoin block chain solves, I seem to have forgotten.  (Who knows, maybe Ceylons infiltrated 95% of my brain, and since my ability to discern fantasy from reality is based on consensus of my total brain power... um... what I'm getting at is that the Ceylons mean us no harm, why don't you try out their client?  I'm 95% certain you'll like it...)

[hazek]

If clients use bip16/17 before 51% of the miners support it, invalid P2SH transactions can end up in the chain, because old miners will think they are valid.
when 51% of the miners upgrade invalid p2sh transactions will be rejected by minersand will never end up in the block chain- so even if an old client thinks it's valid - it doesnt matter , because there wont be any invalid transactions in the blockchain

I'm starting to get the feeling the whole BIP12, 16 or 17 ordeal is a big PR mess brought about by not stressing enough the most important points of it all. I now have a much clearer picture about what's going on and I think my OP was flawed by my lack of understanding of how the Bitcoin system works.

Thanks everyone for clearing it up for me. I still have a concern about how we would deal with 100% of hostile miners which I believe is a possibility but I now believe even that is survivable.

[DeathAndTaxes]

+ many people mine because they already have the pc + gpu for it. thats a lot of small miners who can compete because they dont have to pay for hardware and they usually dont account their time into the price either.

I believe this to be false with the rising difficulty without a rising price of Bitcoins.

Believe it all you want but a large mining farm w/ tens of thousands of dollars and $5000+ annual electric bill is under more pressure from falling (price/difficulty) ratio than a causal miner who's hardware is dual purpose and may have free electricity.

I don't think you will see the concentration you think you will simply because economies of scale don't really exist.  A 40 GH/s farm isn't much more efficient than a 10GH/s farm.  A 100 GH/s farm has no real economic advantage over a 40 GH/s farm.

Generally consolidation in an industry exist when 2x > x + x.

[Costia]

A 40 GH/s farm isn't much more efficient than a 10GH/s farm.  A 100 GH/s farm has no real economic advantage over a 40 GH/s farm.

not necessarily true. a company could create an ASIC and keep it to itself
this will be very inefficient for making a 10ghash farm, but could be better than FPGAS for 10terrahash farms
currently the total value of bitcoin isnt large enough to attract "big players"

[DeathAndTaxes]

A 40 GH/s farm isn't much more efficient than a 10GH/s farm.  A 100 GH/s farm has no real economic advantage over a 40 GH/s farm.

not necessarily true. a company could create an ASIC and keep it to itself
this will be very inefficient for making a 10ghash farm, but could be better than FPGAS for 10terrahash farms
currently the total value of bitcoin isnt large enough to attract "big players"

However they won't be able to keep it to themselves.  If Bitcoin is big enough to warrant ASIC investment then someone else will make it, release it to the public and there goes that "advantage".   That risk alone likely means whoever make an ASIC SHA-256 processor will release it to the public to recover their capital before being undercut.