Necessary protocol improvement; dissent on future mining configuration

[Vandroiy]

Edit:
I put 10 BTC down for a game theory analysis of the Bitcoin fee system as it stands v.s. a system where there is no 'fixed' block limit.  Only what the other miners choose to accept.  Must be peer reviewed.

Haha... you want something from people who know game theory, but by game theory rules, they shouldn't play your game. Say, my theory is correct on both accounts. I now need another person applying game theory to review my statement, but then I'm getting the money. So, being proper in game theory, he won't do it. (Okay, maybe you'll find reasonable game theory experts, ahaha~)

My try on an answer: remember the thread I linked in the beginning of this thread? There's a lot of discussion about the topic there. It's a little chaotic at first, but I think the main dynamics are analyzed there. Sorry about it not being very formal, but this way more people can read it. Here's a summary of the conclusion I came to, and use as an assumption in the thread we're in now:

• The fee system as it stands is dominated by transaction demand over hard-coded transaction supply, unless a miner cartel can force prices for speedy transactions. But that is an external factor, it depends on too many things outside Bitcoin to be included in a game theory analysis. The point is: we cannot rely on the cartel, as nobody supplied a reason why it is likely to appear. (Also, the cartel is a danger in itself, but that's beside the point here.)
• No block limit and no enforced transaction prices: just write a formal version of the thread linked in this thread's first post. frankly, prices converge to verification cost, which is close to zero. That's it, plus again the cartel thing again, which encounters the same problem as in the other model.

I don't really want to unfold this here, that's why I try to keep that discussion in the other thread. I know that's annoying to those who don't agree on that yet, but it's better if the discussion isn't stopped at that point until everyone is convinced.

(Sorry @double post, not editing more in case people subscribed by mail. This frequent editing is a bad habit of mine.)

[1714153367]

1714153367

[1714153367]

1714153367

[1714153367]

1714153367

[1714153367]

1714153367

[1714153367]

1714153367

[MoonShadow]

The whole point of the proof-of-work system is that any direct attack on the system is expensive relative to the expected gain, so that crime doesn't pay.

Your argument relies on this statement, but I have not seen it proven.

The burden of proof is not on me to show that the system is not broken.  And I have seen enough to believe it proven for myself, what you have seen or not seen is, likewise, not my problem.

Edit: I don't see your attacks against the Web of Trust problematic in a real-world situation. Let me take them on one-by-one.

Attacks upon a WoT system are more subtle, and potentially much less costly.  One is simply the act of 'node identity spoofing', faking the identity of a trusted node.  Another is the 'scorched earth' event, wherein a node develops honest trust, and then turns bad once the opprotunity is presented.  You can make both of these attacks difficult technically, but you cannot make them impossible, nor particularly expensive since I do not need any great resources for either attack.  Other attacks requiring coordination are possible as well.  This does not include the basic network attacks upon the hosting servers themselves, the security of which is importan in a web of trust.

• Node identity spoofing is the same as Bitcoin target address spoofing.
  
  

Incorrect.  Your proposal is about the blockchain, and node identity spoofing would be the equivilant of hijacking the identities of trusted miners, but Bitcoin doesn't presently depend upon trusted nodes, which is part of the point of it all.

• 'scorched earth' only works as long as the Web of Trust is small and holds only few connections. Otherwise, the risk falls exponentially with the number of connections.
  

Again, incorrect.  The scorched earth attack involves a node developing trust as the network builds, and only turning malicious after the WoT has grown to such a size that the value of such an attack outweighs the value of continued growth.  Said another way, the scorched earth method is most profitable when the network is mature.

I see no problem. Your attacks can apparently be thwarted neatly.

This is likely true in most cases, but not provably true.  Satoshi's white paper proves that similar attacks are not possible with Bitcoin so long as the attacker has less hashing power than the honest network.  And this is the status quo here.  If you don't like it, prove it.  You are long from that goal.  As I understand it, you don't contest that proof; you just believe that the transaction rules don't promise that said hashing power can be maintained.  And I disagree.[/list]

[Vandroiy]

I suggest building a Web of Trust. You assume participants in the web of trust hold no signature to mark their identity.

Wat? Seriously, what? Okay, since this is apparently necessary, I will add that every participant in a web of trust holds a private key defining his identity. I thought that was common sense. Please, for any statement of mine, try to assume that I'm not a complete idiot so I don't have to paste in the exact definition of everything I say.

Now, assuming we have a "burden of proof" (what the heck, is someone on trial?). Isn't the equilibrium problem description as close as it gets? The cartel structure is the only thing not covered, as it has too many external factors and is bad enough in itself. We cannot just ignore game theory/Tragedy of the Commons because "hey it might work out 'cause all the chaos in the system will make things hard enough". That is just believing something will work.

You say I just believe the network will go to a known equilibrium. Well, you just believe it'll take a nice value, even though you provide no model as to why it shouldn't end up anywhere else. Where's the link between size of the biggest attacker and transaction fees? Is there even a functioning proposed set of rules apart from the arbitrary block size limit? There is nothing in place but the limits, which are a fairly poor long-time solution.

We're still at the proposal "just use high limits", which is known to fail when overpowered, versus an attempt that might be stable even if someone has more processing power. Attack outcome not altered between the two. I see no disadvantage, but a potential benefit.



At scorched earth: two factors. One: scorched earth only ever works on nodes with more trust linking to to sabotaging participants than honest ones. Two: a single node providing the block that came first speedily makes the attacking fraction look idiotic. Yeah, they all had the block all the time, but none cared to send it? Imagine this with a chain of three. The client could mark them as "apparent attackers" without much risk. If they claim they also got it late, the node would ask who sent it with such delay, tracking the origin of the block. It will find the honest fractions in the Web of Trust, all knowing nothing about the supposedly old block. What could they do to sound trustworthy? Someone has to justify the delay, and there just is no reason to create a long delay.

It's just a problem of "which order came first" on a 12 minute time scale in a long-running network. We have the timing, and the chance to remember nodes from the past. We could use this to our advantage, and do what can be done. But we could also just throw the information into the bin and keep hoping we're the strongest petaflop-gang of the world. I don't understand how there can be doubts which is the better option.

[MoonShadow]

I suggest building a Web of Trust. You assume participants in the web of trust hold no signature to mark their identity.

Wat? Seriously, what? Okay, since this is apparently necessary, I will add that every participant in a web of trust holds a private key defining his identity.

I think you misunderstood my point.  Even in Bitcoin, trust is gained by direct interactions, but with those same interactions come identities.  A web of trust works well as a means to identify trustworthy counterparties.

Now, assuming we have a "burden of proof" (what the heck, is someone on trial?).

No, the Bitcoin system is.  You have made an accusation that something is broken, I disagree.  I am the status quo, so it is your job to prove me wrong or end the libel.  Your opinion on how things might go wrong does not qualify.

Isn't the equilibrium problem description as close as it gets?

You have failed to show how your equilibrium problem is actually an accurate discription, while others have already attempted to highlight errors in your viewpoint.

The cartel structure is the only thing not covered, as it has too many external factors and is bad enough in itself.

The cartel problem has been debunked repeately on this forum.

We cannot just ignore game theory/Tragedy of the Commons because "hey it might work out 'cause all the chaos in the system will make things hard enough". That is just believing something will work.

I won't ignore real problems, but nor should we just start freaking out because one guy thinks that he has found the great error in the system.

You say I just believe the network will go to a known equilibrium. Well, you just believe it'll take a nice value, even though you provide no model as to why it shouldn't end up anywhere else.

Again, it's not my problem to show you anything.  And I don't think that it will end up at a nice value, I think that it is a self balancing system that will continuously find it's happy point largely own it's own, and I don't think that it's going to be unmonitored regardless.

Where's the link between size of the biggest attacker and transaction fees?

There isn't one.   Your problem is that you cannot define why there needs to be one, much less what the minimum dificulty level should be.

Is there even a functioning proposed set of rules apart from the arbitrary block size limit?

Actually, yes.  And that has been pointed out already.  And they are not proposed, they are presently functioning.

There is nothing in place but the limits, which are a fairly poor long-time solution.

Maybe they are, maybe they aren't.  Still adjustable.

We're still at the proposal "just use high limits", which is known to fail when overpowered, versus an attempt that might be stable even if someone has more processing power. Attack outcome not altered between the two. I see no disadvantage, but a potential benefit.

And I see no advantage and much potential downside to your proposal.

At scorched earth: two factors. One: scorched earth only ever works on nodes with more trust linking to to sabotaging participants than honest ones. Two: a single node providing the block that came first speedily makes the attacking fraction look idiotic. Yeah, they all had the block all the time, but none cared to send it? Imagine this with a chain of three. The client could mark them as "apparent attackers" without much risk. If they claim they also got it late, the node would ask who sent it with such delay, tracking the origin of the block. It will find the honest fractions in the Web of Trust, all knowing nothing about the supposedly old block. What could they do to sound trustworthy? Someone has to justify the delay, and there just is no reason to create a long delay.

Really?  You seriously can't see the problem with this proposal?

It's just a problem of "which order came first" on a 12 minute time scale in a long-running network. We have the timing, and the chance to remember nodes from the past. We could use this to our advantage, and do what can be done. But we could also just throw the information into the bin and keep hoping we're the strongest petaflop-gang of the world. I don't understand how there can be doubts which is the better option.

We could actually add that to the protocal of the running network without much trouble, I think, but depending uon that for the security of the blockchain is far worse than depending upon the hashing strenght of the entire honest network.

[asdf]

@creighto: Please, let me clarify this debate.

Do you agree that transaction fess will approach the cost of verification? If so, how is it that you don't think this will destroy the network once block rewards are depreciated? If not, what mechanism will influence fees to some sort of equilibrium?

I'm with Vandroiy on this. You claim there is no problem to solve. I'm curious to know why you think this?

[MoonShadow]

@creighto: Please, let me clarify this debate.

Do you agree that transaction fess will approach the cost of verification?

I don't know what you mean by "cost of verification".

If so, how is it that you don't think this will destroy the network once block rewards are depreciated? If not, what mechanism will influence fees to some sort of equilibrium?

I believe that the desires of users to have their transactions processed quickly will drive a market price for fee paying transactions.  Free transactions are charity, and there is nothing that compells miners to include them at all.  When the network is more heaviliy used, the competition for inclusion will drive the transaction fees, and the transaction fees will drive the difficulty.  This is a barely visable effect at present because there is so little traffic on the network compared to it's capacity, but it's already present.  Furthermore, not all transaction fees are voluntary.  Oversized, scripted or other unusual transactions require a fee; for very good reasons.  The -sendtomany transaction used by the mining pools, or something similar, is likely to be used by employers to pay their employees in one action, and a small fee is reasonable.  Any idea how much employers have to pay for those transactions now?  It's a lot higher than .01 bitcoin each week.  I also believe, that at the current rate of adoption and growth of the Bitcoin economy, the transaction fees will compare favorablely to the block reward by the time the first block reward is cut.

I'm with Vandroiy on this. You claim there is no problem to solve. I'm curious to know why you think this?

Because I understand how it all works, perhaps?  I consider that a silly question, honestly.  Transactions are not a Tragedy of the Commons situation.  Sure, all the other users benefit from the security that your transaction fees pay for, but that is not why users pay for the transaction fees.  If the system required the altruistic commitment of users, I'd agree that the system was broken, and then we wouldn't be having this conversation because I'd have never been here long enough.  But it is not dependent upon the altruistic support of users, but in the rational self interests of users who, for reasons of their own, desire rapid confirmations of a legitimate transaction.  Part of the core complaint, as I understand it, is in a future without a hard blocksize limit; under the assumptions that 1) this limit must be raised or lifted soon in order to facilitate scaling up the Bitcoin network (I agree with this one) and 2) that the raising/lifting of this limit will cause the transaction fees to crash even as the transaction traffic grows.  Yet, we have already seen that transaction fees pop up even long before we approach this limit, even as the very low transaction rates we presently see.  Part of this is likely because there is much more to the transaction fees than just a hard limit.  In fact, the hard limit only exists at all in order to prevent the catastrophic spamming of the blockchain if an attack vector were to be found, and isn't part of the transaction fee schedule at all.

[asdf]

@creighto: Please, let me clarify this debate.

Do you agree that transaction fess will approach the cost of verification?

I don't know what you mean by "cost of verification".

This is the cost to a miner for verifying a transaction. The cost is composed of electricity, and infrastructure, etc. It's a small number, but it's not zero.

Now if a transaction fee, weighted by the probability that the miner solves the block that includes it, is less than the cost of verification, then the miner presumably will not accept the transaction.

Why else would a miner reject a transaction? If miner decides they will set a fixed floor on the transactions they accept, they are leaving profitable transactions to their competitors, driving them self out of the market. So, Vandroiy's argument, to which I sympathise, is that miners will reduce their fee floor to relative to the cost of verification.

The cost of verification will get much smaller with growth in computing power. Pooled mining reduces this further because only the pool operator has to verify the transaction.

If so, how is it that you don't think this will destroy the network once block rewards are depreciated? If not, what mechanism will influence fees to some sort of equilibrium?

I believe that the desires of users to have their transactions processed quickly will drive a market price for fee paying transactions.  Free transactions are charity, and there is nothing that compells miners to include them at all.

Higher fee will only be processed more quickly if there exists some sort of tiered fee structure distributed amongst miners. If you believe that fees approach the cost of verification then this tiered structure won't exist. Users will just pay the minimum that the miners will accept, which will be not much more than the cost of verification.

I'm with Vandroiy on this. You claim there is no problem to solve. I'm curious to know why you think this?

Yet, we have already seen that transaction fees pop up even long before we approach this limit, even as the very low transaction rates we presently see.  Part of this is likely because there is much more to the transaction fees than just a hard limit.

What it these fees we see now are just a statical anomaly? people are new to this thing and may pay fees for all kinds of irrational (economically speaking) reasons.


I think I have a solution... I'm a bit stoned so this might not make sense.

We can incentivise fees but imposing a protocol restriction on how miners accept fees. An idea for this is to mandate that only half of the transactions that a miner processes can be transactions created after the last block (new transactions). The rest must be transactions created before the last block (old transactions). This creates a market to be in the first half, for speed processing. Obviously miners will fill it's first half with the transactions that pay fees. Users will compete for this privilege.

[MoonShadow]

@creighto: Please, let me clarify this debate.

Do you agree that transaction fess will approach the cost of verification?

I don't know what you mean by "cost of verification".

This is the cost to a miner for verifying a transaction. The cost is composed of electricity, and infrastructure, etc. It's a small number, but it's not zero.

I can agree the profit margin on mining will tend toward zero, and if it drops below zero, miners will drop out and the difficulty will stagnate or drop until it's mildly profitable again.  This is the self-balancing process that I was referring to.
 will influence fees to some sort of equilibrium?

I believe that the desires of users to have their transactions processed quickly will drive a market price for fee paying transactions.  Free transactions are charity, and there is nothing that compells miners to include them at all.

Higher fee will only be processed more quickly if there exists some sort of tiered fee structure distributed amongst miners.

That tiered fee structure does exist already.  It's part of every client at present, and it's why there are 'soft limits' on free transactions.

If you believe that fees approach the cost of verification then this tiered structure won't exist. Users will just pay the minimum that the miners will accept, which will be not much more than the cost of verification.

I don't know why you don't think that it won't exist.  Users are likely to pay the minimum that miners will accept unless they have some personal reason to pay more for speed of confirmation.  This will only be so if there is significant transaction traffic, and so far there isn't enough to force this issue; even though free transactions can already be delayed.

I'm with Vandroiy on this. You claim there is no problem to solve. I'm curious to know why you think this?

Yet, we have already seen that transaction fees pop up even long before we approach this limit, even as the very low transaction rates we presently see.  Part of this is likely because there is much more to the transaction fees than just a hard limit.

What it these fees we see now are just a statical anomaly? people are new to this thing and may pay fees for all kinds of irrational (economically speaking) reasons.

It's irrational to assume that this is the case.  Show me the math that implies this and I'm willing to listen.  If you can't show the math, you don't have a case.

[Vandroiy]

(...) let's wait and see how it plays out. Don't fix what ain't broken.

Sorry, but I strongly disagree, strongly enough to make a whole post out of that statement. It is important to show that Bitcoin is not like the other currencies, that it is not patching behind the mess.

If there is an attack and we start fixing after fraud has occurred, it will be known what Bitcoin was not: flawless. The same way it will look when somebody proves the system has been wasting millions of dollars on processing power it never needed. Anybody who paid for transactions will feel fooled when that happens. But Bitcoin could be flawless. Right now, it's still perfectly reasonable to use miners. Nothing went wrong so far, and everybody is astonished by that. That's where the magic lies; people look at things and if they see it flawless, they become advocates of it. People like to find good things and support them. The last thing we need is a fix coming in late, making unbroken belief waver.

Bitcoin. A system ahead of time, superior to other currencies at all times in its history. It can be done from here, but nothing is done by blind belief from those making the system. It is essential that Bitcoin shows no signs of failure, not visibly and not theoretically, until it is well-established; better yet, none ever.

Bitcoin is all about trust and doubt now. Trust is all we have, and all we need. I don't think we should ever risk it. "See how it plays out" is absolutely no option in my opinion.

[Vandroiy]

Where's the link between size of the biggest attacker and transaction fees?

There isn't one.   Your problem is that you cannot define why there needs to be one, much less what the minimum dificulty level should be.

Good job on reading one of my arguments correctly, and the thread's topic: we lack a consensus on desired mining configuration. But you agreeing and adding difficulty as another free parameter makes your statement a blatant contradiction to another thing you said, namely

The whole point of the proof-of-work system is that any direct attack on the system is expensive relative to the expected gain, so that crime doesn't pay.

So the miner configuration is such that an attack does not pay, but there's no link between attacker size and both transaction fees and difficulty. That is a contradiction. At least one of those two quotes must be wrong. Please don't force me to formally prove this.



@vladimir:

I have been discussing why I do not believe in your "self healing and self regulating properties" for weeks. I am weary of arbitrary claims of "the" system configuration "being self organizing". Provide anything close to a model that has not been shown problematic, and I will regard it. Also, please do it in the appropriate thread. The quote I took may have been out of context of your post, but the part I ignored is out of context of this thread. Let me quote myself, the very fist thing said in this thread:

We currently have no consensus on future system parameters controlling transaction fees, and thus also the amount of miners. In another thread, I concluded that in transaction fees are determined mainly by market size and the maximum block size. If you disagree, please discuss in the linked thread. In this thread, we assume the conclusion correct.

The discussion is crumbling because people keep shouting "no you are wrong" without staying with the argument. Make up your mind: either you are certain that there is a stable setup in place. If so, which one, limits on or off? Provide the model in the appropriate thread, link to it here, end the discussion as irrelevant in a single post. Or we take the option of "let's wait and see how it plays out". These are mutually exclusive. Either you know something, then there is no need to observe it -- or you need to observe it, but then you don't know.

I usually walk away when I face a battle where a logical construct is attacked with sheer mass, be it amount of people or amount of words said. I'm reluctant to do so here, but please note that this discussion is past the point where a blurry claim persuades those who believe there is a problem. If the thread becomes too bloated, I'll re-create the topic again, if necessary on a different site, until it is either solved, shown not a problem or hitting enough non-argumentative resistance to justify giving up. The latter outcome is a very poor way of resolving disputes though.

But please, at the very least, when talking about "current" Bitcoin protocol, specify whether you talk about a future version or want to live with the limits for all eternity. One cannot conjure up the Bitcoin protocol before it's finished. That goes for creighto as well; when talking in #bitcoin-dev, nobody can point me to any rules in place that comply to your claims.

[MoonShadow]

Where's the link between size of the biggest attacker and transaction fees?

There isn't one.   Your problem is that you cannot define why there needs to be one, much less what the minimum dificulty level should be.

Good job on reading one of my arguments correctly, and the thread's topic: we lack a consensus on desired mining configuration. But you agreeing and adding difficulty as another free parameter makes your statement a blatant contradiction to another thing you said, namely

The whole point of the proof-of-work system is that any direct attack on the system is expensive relative to the expected gain, so that crime doesn't pay.

So the miner configuration is such that an attack does not pay, but there's no link between attacker size and both transaction fees and difficulty. That is a contradiction. At least one of those two quotes must be wrong. Please don't force me to formally prove this.

It's not a contradiction, at least one of your premises is wrong.  Namely, that the size of an attacker can be known in advance.  It cannot.  But the proof-of-work system exists to make a brute force blockchain attack to be as expensive for the attacker as the network as a whole can afford.  What the total network can afford is always changing with the size and overall bitcoin wealth of the Bitcoin economy & userbase.  The beauty of the current system is that it associates a personal need of certain particular users to the collective need of the userbase.  Namely the personal need of well-heeled users to rapidly confirm large and/or high risk transactions with the collective need of the userbase to maintain as high a level of blockchain security as is reasonablely possible.  Your assumptions are that the current protocol cannot maintain the level of security.  I assert that you have failed to show this in any fashion.  Show me how you might guess the level of a future attacker, and I might be willing to entertain flights-of-fancy; but thus far this has all been about how you would have done things differently.  Feel free to go do it.  I'm sure others will try it.  Hell, I might even try it.  But based on what you have written thus far, you still don't really grok what Bitcoin is actually doing to protect itself.  There is more to it than you have expressed, and the smaller rules have an interlocking interplay with the major part of the protocol that actually makes the task of attacking, DOSing or spoofing the network so much more difficult to achieve in practice than it is written into the white paper as a matter of theory.  One such rule is the blockchain release benchmark.  With each new release, the new client contains a list of particular blocks whose confirmed hash number is recorded in a hard coded list in the source.  At present, that list is the same for each client because they are pretty much all the same client.  In the future, the benchmarks would be different for each independently maintained client.  The reason for this list is to protect the history of the blockchain from a successful brute force attack of the blockchain, because in order for an attacker to rewrite the history of the blockchain before the newest benchmarked block, the attacker would have to produce a forged block, that could pass the validity tests, that still had the same hash as the original benchmarked block.  In order for an attacker to continue to succeed, he would have to keep doing this for every benchmarked block in the list; because it's not something that can be changed in the running nodes.  This problem is compounded further if, in the future, alternative Bitcoin clients use an alternative list of benchmarked nodes; as the attacker would have to either do this magic with all the benchmarked blocks in all the alternative clients as well.  The mathmatical difficulty of doing this is probably quantifiable by some of the math geeks on this forum, but my back of the envelope numbers tell me that the odds of being able to do this is so astronomically against the attacker and in favor of the network that, (even ignoring all of the other problems with it such as the near impossible task of just getting back that far with the current ability of the network) the attack would be so many orders of magnitude higher difficulty than the simple single block rewrite that the cost of building such a supercomputer would likely exceed the total wealth of the top 20 wealthiest nations on the planet, and perhaps the entire wealth of the planet itself.  Which, of course, effectively makes such a thing a literal impossibility unless there is some alien race that arrives on Earth in the next 120 years bent on the task of breaking Bitcoin.

And that is just one of the checks beyond the protocol itself that exists within the Bitcoin client.

[Vandroiy]

@vladimir:

Sorry about that, but look at the size of the debate. I can hardly keep track of things as is, and it appears I can't keep the threads split either. I must admit that the split into argumentative and constructive part has failed. Think about it from my viewpoint -- I'm fairly convinced that the difficulty equilibrium needs a re-design, but how can I discuss what follows from that with those who believe me in the midst of the first discussion?



@creighto:

Now we're on the same page. What you describe is a hypothetical check of the exact kind I am asking for. But there is one very big problem: an attack can be very short. It might need no more than an hour of control to fool people into believing in the transactions that are to be reverted. The block sealing has to happen fast, within ten minutes or so. We can't wait for a new client version, also we don't want to put too much trust in a client author. So how can it be implemented? How can you be certain you have sealed the correct block, you have the correct hash? All attacks on a web of trust work against this, and more due to centralization. What we need is to formulate this idea to the end, so it can be implemented. That's just not an easy problem. On a side note, whether or not it is in the protocol is only a formal question. Since the clients would have to enforce it, any such rule-set becomes an effective part of the protocol.

The web of trust is one proposed possibility that might remain secure when your ISP or router is compromised. If someone manages to add the security enhancements you describe in a different way, this thread is obsolete and I'm happy with the outcome. I just wonder how exactly to do it, and would love to see it implemented sooner rather than later.



On the contradiction mentioned in my last post: I do not assume the size of an attacker be known in advance. I just assume there is some attacker of some size at some time. I will continue where I left off, showing that one statement must be false.

Statements:

• There is no link between the size of the biggest attacker and transaction fees.
• Any direct attack on the system is expensive relative to the expected gain.

Let me assume the second statement true. This means the amount of the attacker's BTC that can put into transactions simultaneously is worth more than the processing power required to execute the attack times some risk factor. The processing power required to execute an attack is obviously linked to difficulty.

But difficulty is effectively an expression for the amount of mining power present, and that is paid by the total amount of transaction fees: average fee times amount of transactions, put simply. I have now established a link between size of the biggest attacker and transaction fees, with one free parameter, namely the amount of transactions, or market size, if you wish to put it that way.

Thus, if statement two is true, statement one is false. I conclude that one of the statements must be false.



Interpreting this is a different thing. Yes, we need the link to keep things safe, so that's not bad in itself. But there is one free parameter, the market size, and absolutely nobody can tell me what to do with it. Now, if that's not a discomforting sign, what is? As stated before, I personally believe the first statement to be close to the truth, and the second to be false with the current client.

PS: I take the minus reputation as a compliment. At least I pushed hard enough that people feel to use this in place of arguments, displaying how the feature is now used for democratic truth-seeking. Too bad truth is not democratic.

[MoonShadow]

@vladimir:

PS: I take the minus reputation as a compliment. At least I pushed hard enough that people feel to use this in place of arguments, displaying how the feature is now used for democratic truth-seeking. Too bad truth is not democratic.

I didn't do it.  Is it still a compliment?

[Vandroiy]

PS: I take the minus reputation as a compliment. At least I pushed hard enough that people feel to use this in place of arguments, displaying how the feature is now used for democratic truth-seeking. Too bad truth is not democratic.

I didn't do it.  Is it still a compliment?

Forget about it, that system went haywire much faster than I expected. There's already a majority voting inverse... lol I wasn't posting anywhere but here when I got the two negatives, and my post was fairly aggressive, so I guessed it's related. But I didn't want to accuse anyone.

Maybe someone who's not even talking in here voted negative on both sides to make participants in the discussion angry at one another. I feel like a loser now, having been successfully trolled, even if just for a sentence.

It's good I don't have 250 posts yet. I can prove my innocence in reputation wars.

[stillfire]

Maybe someone who's not even talking in here voted negative on both sides to make participants in the discussion angry at one another. I feel like a loser now, having been successfully trolled, even if just for a sentence.

This is a forum of strong opinions. I wouldn't be surprised to see everyone have a negative reputation on average!

[da2ce7]

@Vandroiy

There have been many people that have passionately said that 'Bitcoin was wrong’ back in early 2010, and they said that it would never get even close to where it is now.

The free market is much more flexible than what you describe.  Did you know that in a free market dominated by Bitcoin, that 'everyone' would be advantaged by its stability?  So the risk to attack may be very very small.  Therefore making Bitcoin more inefficient by artificially shifting more resources into mining may make Bitcoin even less secure as people will not use Bitcoin but something that is cheaper.

The fact is that 'we don't know' what is going to happen... We just know that bitcoin so far has been very successful, and that throughout history a free market has been very successful at predicting and working around any 'attack issues.'

Artificial restrictions are stupid and should be avoided.  I disagree that there should be a fixed fee schedule and block size... I think that it would be more accurately described by competition between the miners.  At some point, Bitcoin may be so cheap and fast, and require such a large amount of infrastructure to run that the people running the network would have a strong stake in keeping it secure.

Vandroiy, you ignore 'idle resources;' good people may have huge computational resources just sitting there for use as a deterrent to any attacker... Those resources could be sponsored by each the big bitcoin banks.  An attack will never happen, because it would be prohibitively expensive to undertake... not from the active network power, but from the potential.


In any case, there is so much about the future that we don't know... and this is all speculation.
We should focus on making Bitcoin as secure as possible NOW, not 50 years in the future.

[Mike Hearn]

I think it's worth thrashing all this out, as these debates over the stability of a purely fee driven chain keep popping up in other places.

The current best proposal I've seen is to have people pay miners directly, by the gigahash, for work done on top of a transaction (ie the work paid may span multiple blocks and is thus not for inclusion). Insurance companies sit in the middle and calculate the risk of any given client being attacked, and charges them premiums for reversal insurance measured in time.

If a client starts getting attacked by people trying to outrun their transactions, the insurance companies will pay miners more to bury the transactions under more gigahashes of work done. Fees would not be provided via the current input/output value deltas but rather are paid directly to miners. It means you can't observe a high-fee transaction be included, pay for the minimum amount of hashing needed to enter the next block and then benefit from the next run of 6 accelerated blocks, because you don't know how much work has been paid for. Even if the network suddenly speeds up due to a high-fee transaction, the work might complete 5 seconds after you submit your transaction for inclusion.

In this world the minimum price for inclusion would vary and be essentially up to luck, you'd have to maintain accounts with a bunch of miners (how many is your choice) and keep draining your balance until a block is found. Overall your fees will be the average number of gigahashes taken to find a block multiplied by the current cost of a gigahash, set by market rates. That market rate prices in the benefit of the work done on top of your block. For a merchant if the average speed of the network is X gigahashes of work done in 24 hours, you need to dispatch your goods in 24 hours and X is enough work to avoid an attacker reversing the transaction after you dispatch, the only fees you need are whatever it takes to get into a block (ie you pay until you get in, then stop paying). If you need more security, like X gigahashes in 2 hours, you'd pay more and the network would temporarily speed up before reverting to the mean.

I've been debating this with someone and put the above system to them. They claimed the best strategy for people is to never pay anything, regardless of what you think anyone else will do. I don't really know how to convince him otherwise, as "paying nothing to anyone" is clearly not a winning strategy if you want to be a part of the chain!

I think it's worth keeping an open mind about the proof of work aspect of Bitcoin though. Satoshi wanted to design a system that didn't require any trust at all. Whilst we sometimes say Bitcoin doesn't have any middlemen, in reality it has a large number of middlemen who help people who don't trust each other trade. You don't have to trust the middlemen either, making it (theoretically) a very open and liquid market ... at the cost of burning a lot of electricity.

It may be that the zero-trust configuration isn't actually the best or most useful in the end, if the benefits of a fluid market aren't outweighed by the PoW costs. The proposal of using a web of trust to order transactions rather than PoWs has the disadvantage that it raises huge barriers to entry (how does a new node become trusted in such a system, without opening it up to easy attack?), but the advantage that the energy costs are very low.

[FreeMoney]

I think it's worth keeping an open mind about the proof of work aspect of Bitcoin though. Satoshi wanted to design a system that didn't require any trust at all. Whilst we sometimes say Bitcoin doesn't have any middlemen, in reality it has a large number of middlemen who help people who don't trust each other trade. You don't have to trust the middlemen either, making it (theoretically) a very open and liquid market ... at the cost of burning a lot of electricity.

It may be that the zero-trust configuration isn't actually the best or most useful in the end, if the benefits of a fluid market aren't outweighed by the PoW costs. The proposal of using a web of trust to order transactions rather than PoWs has the disadvantage that it raises huge barriers to entry (how does a new node become trusted in such a system, without opening it up to easy attack?), but the advantage that the energy costs are very low.

Absolutely, I don't need to pay a bunch of miners to facilitate trade between people I trust for more than the amount involved. Bitcoin just opens my trading world up from like 6 people to potentially 6 billion.

[Mike Hearn]

Yeah. I guess my point is, we shouldn't close our minds to alternative designs.

I mean Vandroiy already convinced me the existing setup where all transactions are flood-filled to the network with attached fees won't work. The insurance/pay-per-gigahash model is a slightly different scheme, whether you think it's Bitcoin or not Bitcoin is, I guess a matter of opinion. Now I'm getting convinced the insurance/p-p-g model won't work (well) either.

The problem with a single chain is it sets a single speed and security level for everyone, though transactions have wildly varying tolerances to risk. For trading with my family I don't need any PoWs at all. For huge trades between people who don't trust each other you need way more than the average. Most trades are probably for internet type purchases today, probably less than a few thousand dollars worth of value.

Some people will over-pay, others will underpay (free riders) ..... it's not clearly the best solution.

However, I don't know what a better solution would be right now.

[FreeMoney]

Yeah. I guess my point is, we shouldn't close our minds to alternative designs.

I mean Vandroiy already convinced me the existing setup where all transactions are flood-filled to the network with attached fees won't work. The insurance/pay-per-gigahash model is a slightly different scheme, whether you think it's Bitcoin or not Bitcoin is, I guess a matter of opinion. Now I'm getting convinced the insurance/p-p-g model won't work (well) either.

The problem with a single chain is it sets a single speed and security level for everyone, though transactions have wildly varying tolerances to risk. For trading with my family I don't need any PoWs at all. For huge trades between people who don't trust each other you need way more than the average. Most trades are probably for internet type purchases today, probably less than a few thousand dollars worth of value.

Some people will over-pay, others will underpay (free riders) ..... it's not clearly the best solution.

However, I don't know what a better solution would be right now.

What insight am I missing? Can't you just do very low tx fee with your family and friends to 'prove' you don't really need good and fast service? Then if you get it anyway no one is hurt by your riding because the tx is so cheap to process, if you have to wait that's a risk you take. If you can't afford the risk you pay more, the spillover benefit doesn't hurt you. In a tiny way it helps since people who use the same money as you benefit and you are better off when your (potential/statistical) trading partners are better off.

I kind of hope I live another 118 years just to see the system keep working without block rewards. :-)