Topic: A startling thought crossed my mind (Read 2969 times)

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.

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"

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.

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.

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

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

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)


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.

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

https://bitcointalksearch.org/topic/m.726268
https://bitcointalksearch.org/topic/m.711055
https://bitcointalksearch.org/topic/m.709359

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

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

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

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?

It's called backwards compatibility.

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

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.

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?

If I passed you a block in which I awarded myself a 100BTC reward for generation, you're client would just be like, "Lol, no. I don't care who else accepts that, I don't". Same thing if someone tries to give themselves 50BTC for block 210000.

They can tell its legitimate because its in the blockchain in the first place, that means a miner produced it according to the rules of the bitcoin network. If whatever percentage of miners decided to change the rules, they are NO LONGER recognized by the blockchain, they simply dont exist as far as the bitcoin network is concerned.
 

If there's new rules, it won't be validated by an old client.  The old client has old rules, and checks to make sure all of the transactions are using old rules as well.  If someone introduces new rules, even if they have 2000 times the hashing power of the current Bitcoin network, the current Bitcoin network still wouldn't accept that new blockchain, since it wouldn't validate to the rules that are built-in to the client.

EDIT:  Basically, it's not JUST the longest blockchain that is accepted, but the longest blockchain that uses the same rules that are hardcoded into the client.