Topic: [If tx limit is removed] Disturbingly low future difficulty equilibrium - page 4. (Read 37667 times)

You're right, actually I didn't think a lot about solution to this problem, I was focusing on preventing double-spending. In any case I think solving this will be easier if we solve double-spending via other means.

If you need to receive a large transfer from someone, you know that it may be profitable for him to mount a >50% attack in other to double-spend it, so you need some sort of guarantee that the transaction is secure before you accept it.

When you receive a smaller transfer it is much less likely that the sender will be willing or able to double-spend it, and much less risky if he does.

I just had an idea. Maybe stupid.
For large transfers maybe you want spread the risk in various blocks instead of just one. My first though was to put the same transaction in various blocks with a special condition that says that the transaction is only valid if it appears in say, 10 different blocks. The miners would share the transaction fee. But then I though that this was equivalent to just wait for more blocks to bury your transaction deeper.
If the transaction is not valid (and thus spendable by the receiver) until X block are on top of the block in which it appears, we can have slower but more secure transactions depending on the needs of the user. We just need another field with each transaction that tell the miners how many blocks have to be between this transaction and the next spend from its outputs.

Let's have an example.
I'm the attacker. I send 1000 btc to buy something expensive. The seller waits for say 6 confirmations and gives me the product. Then I (with my super-miner) cancel the transaction (by creating a parallel and bigger chain) and send it to another address (double spend). The seller is sad.
He could wait until 100 confirmations to give me the product, but then, after 3 he could take the money and run. In that case I would be sad.

Now with the confirmation counter, if I set it to 100 confirmations, we can wait for the 100 blocks and I'm not scared that he gets the funds after 3, without giving me the product.

Does this make any sense?

This would make undoing transfers very difficult, but you could still hold the network hostage. Short-selling strategies could still be profitable.

I'm not sure I understand about large transfers. How does this apply to them in particular? Also can't large transfers be easily disguised by breaking them up into numerous small transfers?

We don't know. I estimate it's higher than necessary. But the security sustainable without either coinbase or prohibitive tx fees will be much, much lower, and we don't want to roll the dice thinking maybe the sustainable amount will be sufficient.

I think you'll be disappointed, AFAIK this was mentioned late in this thread. You may want to search for the post about proof of stake by QuantumMechanic, from which I got the general idea.


I need to research this more, yes. But what I had in mind is a targeted attack against a particular node, trying to isolate it from the network and feeding it blocks distinct from those known to the rest of the network. I think it's possible to do that, and while I don't know if such an attack can be lucrative, the victim node can never recover if it adheres to your protocol rigorously.

But if it turns out to be a viable means for increasing security of large transfers (for which a day of waiting would be acceptable) then by all means, proof of stake won't be needed.

This is the part I'm having problems with.
You're saying the current security is 7.5%. Is that too much? Too little?
What are you basing on?
Of course it would be great to increase security without increasing costs for the network. But the stake-proof system doesn't convince me yet. Maybe is because there's still many proposals for that system.
I'm re-reading the thread from the beginning anyway, to see the stake-proof proposal a like more.

Bernanke can destroy either system with his pinkie finger. I think we should be thinking about malefactors of a lesser order.

Figuring at $1000/ Gigahash, you need maybe 7500 gigahash to control the network. Currently, that is 7.5 million USD, or 7.5% of BTC market cap. Say instead you have a system where you need approximately a 20% stake in btc wealth to control the network. Currently, that is 20 million USD (20% of market cap).  The gigahash % of market cap will fall dramatically as mining rewards fall. The proof of stake % could remain stable over time.

But what about non financial attacks? Say Bernanke trying to destroy bitcoin.

So the blocks are 3MB instead of 1MB, extra storage and bandwidth seems like a small price to pay for avoiding regular security disasters.

The incentives to abuse power are not there. The major coinholders need to sell their coins to minor coinholders to divest themselves from the system. If they abuse minor holders, the coins they hold will lose value. The situation is very different from a typical shareholding arrangement where there are physical assets for major holders to expropriate from minor ones. For currency, trust is perhaps the principal resource that gives the holdings value. Abuse trust and the value can rapidly evaporate.

The miners on the other hand are much closer to disinterested third parties. If they commit abuses, there are no obvious consequences for them.

Transaction limits (roughly) triple the size of the blocks.  First, someone sends you money, then you send it to yourself again, but this time with your wallet policy information included.  Not a big deal today, but in the future...

One other objection to the stake idea.  Whatever function we make that system do is power that we are granting to major coinholders over the minority network.  The smaller the number of entities involved, the easier it will be to abuse, and without recourse.  Extreme care must be exercised.

I also prefer a mixed hashing-stakeholder system, but don't agree that the standalone system is pointless.

I agree with you about the large wallets online issue. However, this in itself is a serious flaw that needs to be addressed.

To solve the problem, why not allow users to specify txn limits on their wallets? For example, I create a wallet that has a user-specified send limit of 1 BTC per block. The wallet also has a user-specified emergency address where the money can be sent without limit. The wallet-specific txn limit and the safety address are recorded in the blockchain. If I detect unauthorized txns,  I can empty my remaining coins into the emergency wallet. If I'm really securing a lot of money, I can create a 'safety' chain of wallets with txn limits. To steal a reasonable amount of money, the attacker would have to control every single wallet in the chain. Voila, a large wallet can be stored online safely.

As far as gathering, distributing, and verifying... You only really need information from people with a relatively large amount of coin. You could just place a limit on the minimum investment necessary to mine. Smallholders would not need to participate in verification. Voila, the network is much smaller.

You need to think this scenario through a bit more.  Ask yourself what circumstances must occur for a node to be unable to rejoin the world after a network split.  I'll give you two hints.  For the network to get stuck, there needs to be mining power on both sides of the split.  And the duration necessary for the split to become permanent is directly related to the split ratio in a way that makes an honest split of sufficient size and duration to be extremely unlikely.


So, just add a second hash to each script with a stake signing key in addition to the existing spend signing key?  I'm not a big fan of that, but I can see how it would nullify that particular objection.


I bet it would be a lot more than you think, if you consider the fraction of bitcoins held in wallets that are unlikely to participate.  At any rate, like I said, hardly unsolvable either way.

This throws away exactly what the "longest chain" rule was supposed to prevent - a node being unable to catch up with the rest of the network after a period of isolation. You'll want some way to recover by checking which branch is the real one... From a "trusted" source, whose signature you'll want. So might as well make it part of the design.

As I mentioned you don't need the private key required to sign proof-of-stake to be the same one needed to send coins. You'll keep your sending key well hidden offline, while the stake key will be online doing signatures. If someone steals your stake key, you just move the coins to a new address.

Given the distribution of bitcoins, I don't think 3.5M BTC is that many addresses.

the 50% hashing flaw can hardly be considered. the amount of gpus being made would simply not be enough to overpower the network. simply put you would not be able to buy that many even if you had all the money in the world. and if you did have a lot of money, enough to buy a factory, it still would not be enough. not only do you need way more than 50% for a successful attack, you also have to face problems like normal network hash rate increases.

I should point out, yet again, that it would be trivial to change the attack protection function from a multiplier to an exponent.  If nodes refused to revert the block chain unless the change in difficulty was more than 2^(n-5) times the current difficulty when n>6, a vendor could wait a few of hours for a big transaction and be sure that all of the computing power in the galaxy would be unable to reverse it.

That is a slight exaggeration.  It would really take a day or two for that level of security, particularly considering that we are unable to estimate non-human computing power.  But 2 hours would require an attacker to have about 64 times as much power as the rest of the network combined, and 3 hours would boost it to around 4096 times as much.

And I've softened slightly in my criticism of stakeholder signature schemes.  I can see how they could be useful, in theory, but only as an addition to the current header hashing system.  But as a standalone system, it is still pointless.  Oh, and there are horrible operational problems that will turn up if you ever try to implement it.  For starters, it requires the largest wallets in the world to be online, and they are exactly the sorts of wallets that you want to keep offline.  And the problem of gathering, distributing, and verifying signatures corresponding to 3.5 million BTC (and growing every day) is hardly unsolvable, but still immense.

That's what we're talking about.

I don't have millions of dollars to fund this experimental attack.

the only flaws i can see are holding blocks back, spamming the network, and the over 50% hashing power flaws. if you know of some amazing loop hole or something then by all means, exploit the network and set it in ruins. i in fact encourage it, i do not want to use a currency with fundamental issues at the core.

but also keep in mind, if another currency were to ever grab a foothold in the bitcoin market share, then both would suffer.

Rewriting the rules will likey cause a major disruption. If this a disruption is necessary, it will be much less costly now than it will be if implemented after bitcoin takes off. Continued operation with a deeply flawed protocol may prevent the currency from ever taking off. A likely scenario is that another currency will develop better rules and supercede bitcoin.

I like Bitcoin as it is currently, and to be honest i really don't think a 51% attack is going to happen, i was just brainstorming hypothetical approaches to discouraging 51% attacks. Adding the data to the block chain would be just a could of bytes per block, and over the course of 100000 blocks i may add 5 or 6 megs to the size of the block chain. The stamping solution requires no change to the protocol what so ever, blocks already support custom data areas, this would just be putting them to use. I really dont think its needed, but i think its good to know its possible and it could be implemented today as no changes to the protocol is needed and the rest is comparability simple. 

You are centralizing bitcoin right there, requiring the client to ping pools and get data that could very well be forged. also how do you get the clients to ping the pools, if you tried somthing like DHT then it would be open to abuse, just open up any web server and pop in 50exohash/s and fuck up the network. and adding a stamp to the blocks would add more data to each block, and right now we are starting to see the chain getting big, in 10 years the block chain could be over 20x bigger than it is now, we don't need to put more data in it.

what i see now in bitcoin is an almost perfect system, why would you arbitrarily change it when there has never been a problem or currently have a problem. any predictions are only that, predictions. we have never had anything like this before and we will only see the problems arise when it hits mainstream and the cracks open up or over a period of more than 5 years.

There are a couple of options here, clients could ping the pools themselves and ask for generation data and take a look at the block chain, then preform the percentage math locally. You may notice that having clients ping every major pool on start up would be rather resource intensive, although not too bad as major pool will have the hardware to handle it.  A better way to do it would be to get pools to 'stamp' blocks they generate, just as Santioshi included a sentence in the genesis block pools could include a 'Mined by: Deep Bit' in their blocks, allowing clients to simply look at the block chain over the past few hours and do the math locally.