Topic: Government vs Bitcoin ? - page 3. (Read 5996 times)

Attacking bitcoin with CPU power is one of the most stupid, expensive, difficult way to destroy a currency.

If there was a malicious takeover, you could opt to hold your BTC until a solution is figured out.  Maybe something like coming up with new client software that accepts as valid only Bitcoin that was held pre-freeze (i.e, only as-of a certain block, ... anything traded after was ignored).

If that is a solution, then maybe this same tactic is like an insurance policy against a massive theft.  Lets say somehow mtgox loses their entire store of BTC holdings.  Lots of unhappy folks I presume.  Build a new client so that blocks occuring after the theft are ignored.  Put out a call to the general public to use the new client so that 50% + 1 of node hashing is on the good side, and Bitcoin is back in business.

But you are right.  Could become a new type of arms escalation.

I don't understand this, but I'm not a programmer.

Good, that makes my concerns irrelevent.  Even if there were a way to fake a set of transactions without breaking sha256, the ability of the lightweight client to reach out and find another opinion makes any such future exploit pointless.

Not at all. The transactions form a hash tree, and the root of this tree is in the block header. The headers, of course, are verified through the Bitcoin proof-of-work block chain system. The attacker would have to break SHA-256 in order to give you fake transactions.


Yes. You can also request specific transactions by hash, which would be useful in this scheme. If two lightweight clients are dealing with each other, they might want to rely on the network to provide the transactions required for the Merkle tree.

Sounds like you would be trusting that the peer that sent you the relevant transactions to your new transaction to not be sending you a doctored set.  There would be no way to be certain that what you received were real transactions without the complete blockchain, but you could increase confidence if you could download one or more copies of the relevant blocks from random peers not currently engaged in trading with you.  Does the protocol permit a lightweight client to download a specific block from a random peer, or does it have to download them in order?

Lightweight clients only need to store the parts of the Merkle trees that pertain to them. So if I am storing nothing but the block headers (no trees), someone sending me a Bitcoin transaction can send me the new transaction plus the required "branch transactions" in that block (usually not many extra transactions would be required). I can then reconstruct the Merkle root and verify the network's acceptance of the transaction without downloading a single entire Merkle tree.

This relies on the network's verification ability only. Such a lightweight client would not be trusting anyone.


I don't care about the requirements for mining. The average person should not be mining. The sooner dedicated organizations are doing all the mining, the better.

With the Bitcoin system, lightweight clients only need to download and store 80 bytes per block, plus temporarily a few extra transactions for every transaction they receive. Balance sheets requires storing and downloading a lot more data.

This topic needs it's own thread, but I don't understand what is being argued here, if your client is using a trusted server, then it's already a thin client, which only really needs the transactions that pertain to the chain of custody that leads to your balance, so that you can create the transactions to spend them.  If you are using a trusted server to verify the validity of transactions, your client doesn't even need a balance sheet at all.  Using balance sheets, your client cannot independently verify a transaction of a sender at all.

You don't need to know the contents of every other transaction. You need to have a current list of all the unspent coins and to keep abreast of the changes when they are spent. Spent transactions can be forgotten forever. The advantage of balance sheets over lightweight clients is that lots of the block chain can be forgotten and there are not merkle tree stubs hanging around which are a non-trivial size.

No. Balance sheets are script friendly as they would store the scriptPubKeys of all the unspent coins. I'll admit that when I came up with the scheme I was hazy about how scripts work.


Could you please explain what the real problem is? Balance sheets was intended to enable a fully featured mining-capable client while considerably reducing storage requirements. I believe that hard disk space will become a problem for average users long before network bandwidth or cpu usage.

I'm sorry I didn't notice both your continuations of this thread until today.

ByteCoin

You're currently allowed to make complex transactions that can, for example, be redeemed by either of two public keys (whoever gets it firsts wins). This would be impossible in a balance sheet system unless you also record the transaction script, and if you do that you're right back at full transactions.

I don't really see how a trusted list of PK's and their balances isn't sufficient to decide whether a transaction is valid or not.
You wouldn't be able to go check each individual transaction relevant to a single balance, but as long as the balance sheet is signed by some trusted authority, or some hash of it is spread on the network I would be ok running such a generating client.

I'm assuming that when a transaction is made, both public keys are somehow broadcasted to the network so a complete credit list can be computed incrementally.

amirite or am i still missing something here ?

To be able to say, "No other transaction has spent these coins," you need to know the contents of every other transaction. There's simply no way around this. Balance sheets would reduce the space required for each transaction, but this would remove the useful script functionality, since every transaction would need to be sent to exactly one public key or hash.

Balance sheets are basically "simple transactions":

Even with balance sheets, you'd still have 100-200 bytes per transaction, which doesn't help the network end (the real problem).

Yep, assuming block generation reward won't decrease, and that the bitcoin economy will be very liquid with lots of transactions...

In my view, if bitcoin gains momentum and credibility, most transactions will take place inside dedicated services (some BTC bank credits the merchant account while charging the customer for example) and won't be going inside a block.

I don't really see how suggesting that a program, running in the background, and taking 10% CPU on really low priority is a silly idea. If 20% of the people actually close it, 80% will just click the cross, send it in the task bar and help secure the network without even knowing it. As long as the fan doesn't go nuts and my desktop remains responsive I personnaly don't care about 10% CPU more or less. So I'd be really interested in some elaboration on the sillyness of this idea.
And when I'm speaking about mandatory, I'm obviously speaking about the default widespread client, not about what the protocol should enforce.


Why would a generator need to check for double spending ? Actually, a client needs more disk space than a generator.
The only thing a "pure" generator needs is the hash of the previous block whereas a client that receives payments needs to actually check for double spending, be it with a trusted balance sheet or with the complete block chain.
So that's a non-issue.

EDIT : Well I guess a generator needs to check for double-spending when including incoming transactions, but that doesn't really change much since that could be solved with balance sheets, simply by network rejection of blocks that contain invalid transactions after they've been generated, or by a much smarter solution =) I didn't think of.

It's possible for non-generators to store almost nothing. However, the purpose of the network is to verify that transactions are not double-spending, and this is only possible if the generators know all of the current unspent transactions.

Ok agreed, i haven't thought of that.

Your arguments satisfy me for today, thank You

You have it backwards. The government of Tuvalu could run a double spend attack right now, I don't know their exact resource situation, but I'd bet that they won't be able to do it in 6 months. As generating becomes more difficult it will be that much more difficult to overtake the whole network.

We don't have to worry about governments for now because you can't get your name in the papers for taking care of a non-problem that no one cares about. If you want to do anything in government you need an ad campaign first (Yemen?). The ad campaign will ironically boost usage. If there ever is an attack there will be huge forces rallied for good (and profit). Government thrives when it can divide and conquer the population (first they came for... and then...). Maybe they will crush bitcoin, but they will have to beat every one at the same time.

The solution is built in. Pay people to generate and pay them even more if transactions pile up.

We don't need to worry about those with commercial interests (such as the controllers of the botnets currently being used to send spam). For those people, it will always be more profitable to mine for bitcoins than to try tricks like double-spending.

And if those "bad guys" are mining bitcoins it helps protect against the other "bad guys" (those with political motives).

There is a problem with this approach.

Sooner or later, when generating coins becomes too expensive in both bandwidth & processing power, network will be easily overrun by governments, botnets, crackers & other attackers with powerful connection & hardware.
They will also try double spending attacks & different attacks.

The problem will only get worse as there are more and more transactions. So it is better to think of a solution now, instead of cry when the crisis hits.

+1

"Mandatory" generation is silly since people who don't want to generate will just close it and like it less since it's annoying. Not to mention that anyone can write a client that doesn't do it automatically anyway.

I think generation should always be off by default, on a fresh install.

Otherwise, people will start complaining in public "bitcoin makes your computer go really slow", "bitcoin sends your privatez across the internetz" etc, and bitcoin's reputation will go downhill.

It's much better that people, in their own good time, discover how to turn on generation and think "wow that's really cool, I'm helping the system to operate AND if I'm lucky I might get some cons".