Funding network security in the future

[Peter Todd]

Mike locked his original thread unfortunately, so I thought it would be good to continue the discussion about assurance contracts here. Specifically, how to make them work, as well as other possible mechanisms. Regardless of what happens with the blocksize it's important in the long term: without the block limit we can expect transaction fees to fall to the marginal costs of a transaction, which means the fees aren't paying for any security at all, on the other hand, with a small blocksize limit, as I've been arguing for, you still run the risk that off-chain transaction systems get 'too good' and so few transactions actually happen on-chain that security still isn't being paid for. Mitigating both issues is the fact that we've got until about 2033 until the inflation subsidy decreases to even 1% - if keeping Bitcoin secure costs a few % of the value of the Bitcoin market cap every year in the long run, maybe Bitcoin is just too expensive?

An assurance contract, also known as a provision point mechanism, is a game theoretic mechanism and a financial technology that facilitates the voluntary creation of public goods and club goods in the face of the free rider problem.[3]

The free rider problem is that there may be actions that would benefit a large group of people, but once the action is taken, there is no way to exclude those who did not pay for the action from the benefits. In Bitcoin the problem is that mining is costly and benefits everyone who owns Bitcoins and/or performs transactions. A mining assurance contract needs to be constructed in such a way that participants agree that if some large amount of funds are commited, those funds will go to mining in some way, with the amount set to be large enough for a sufficiently high percentage of the economic activity of Bitcoin must have participated to avoid the free rider problem.

Bitcoin already supports assurance contracts as a transaction type[4] - for a mining assurance contract the transaction output would be set to either an anyone can spend output, or an address owned by a specific miner. However as-is they have a serious problem: a miner can always collect the funds pledged to date by simply adding a sufficient amount of their own funds to the outstanding contract, and mining that transaction themselves, thus turning the contract into a simple donation.[5] (modulo the small chance of the block being orphaned; if the chance is large, the assurance contract is not encouraging orderly mining) The problem can be mitigated somewhat by forcing donators to reveal their identity in a provable way, but then high participation is difficult to achieve.

With nLockTime a transaction can be created where the miner who will actually collect it is unknown in advance. As the deadline approaches, if the contract is not fully funded, participants double-spend their pledged transaction outputs to invalidate the contract. However this mechanism has the problem that anyone can make the contract fail, even if it is fully funded. That problem can be solved if Bitcoin's scripting language is extended to allow for transaction outputs that can only be spent by transactions following certain forms - the outputs would be locked to the contract until some time after the contract expires.

Funding network security

I wrote the above in the Wiki, and I think with the nLockTime + transaction templates fixes it's a workable approach that truly acts as a proper assurance contract, so technically speaking I think the idea works. Economicly and socially? I'm not really sure - at that point implementing proof-of-stake or even just signatures on blocks by trusted third parties might happen instead. It's hard to know, but what's important is the option is there.

I also really like Gregory Maxwell's Transaction checkpoints:

Each transaction (or signature?) should contain a block index and 32 (?) least significant bits of the block hash. The transaction's fees are only valid (or only their full value?) if they are mined in a chain they agree with. This would let people making bitcoin transactions 'vote with their wallets' on the identity of the chain they consider important. This isn't a viable POW replacement, but would greatly reduce the economic benefit of mining moderate depth forks, esp as fees begin to dominate the block reward. "You don't get (all) of my fee payment if you are mining a chain I don't like!"

• Nodes would typical checkpoint a few blocks in the past from their current height to avoid overstating their opinion unnecessarily.
• Deep checkpoints could be automatically triggered by observing a critical mass of coins-day-destroyed confirming them— creating a PoS-ish system, though this is subject to the 'nothing at stake' problem of PoS, and is probably very dangerous. (e.g. isolation risk for newly bootsrapping nodes)

User:Gmaxwell/alt ideas

Essentially they're acting as a really fine-grained way of saying which version of Bitcoin history you support, and thus which version of Bitcoin history your transaction fees can go to. If the blockchain is re-orged deeply enough that the version of history now does not agree with what you agreed with, the miner who did that doesn't get your fees at all. He proposed it in the context of my Discourage fee sniping with nLockTime pull-request, it's essentially a much, much stronger version of it, albeit one that requires a hard-fork.

What's interesting is you can combine transaction checkpoints and assurance contracts to create a contract that miners can only collect if they follow the wishes of the people funding the contract. The way it would work is you would first commit some funds to a transaction that can only be spent by an assurance contract for some amount of time. Next you find a contract you agree with, including what transaction checkpoint the contract will have, and quickly (within 2-6 blocks) add your inputs to the contract transaction. If enough people commit, it goes through. If not, you can find another contract, or wait until your locked transaction ouput expire and send the money back to your wallet.

Now if the chain gets re-orged, the rules are that the new block can't collect the fees from the checkpointed transactions. Gregory Maxwell suggesting adding those fees to a pool given to all miners over time, but I think perhaps simpler, and easier to construct short proofs of, would be to just add a new rule that turns those fees into a transaction output that can be spent subject to some conditions. This could be done directly as a scriptPubKey/txout:

Code:

<32-bit partial block hash> IS_HASH_IN_CHAIN? IF <tx out goes to fees> ELSE <pubkey> OP_CHECKSIG ENDIF

The overhead here might be too much given a limited blocksize, and again I'm not sure that socially or economically the idea works, but technically speaking I think it's feasible. Thoughts? I'll add the transaction checkpoints stuff, with and without assurance contracts, to the Funding Network Security wiki page as yet another future possibility if the idea withstands scrutiny.

[1715432059]

1715432059

[Peter Todd]

Also, if someone wants to add a section to the wiki on non-proof-of-work forms of security that side-step the funding issue, proof-of-stake and trusted checkpoints for instance, that'd be good too. Strictly speaking, the result wouldn't be "Bitcoin" anymore, but at the same time, Bitcoin is a consensus and the economic majority can chose to change what Bitcoin is. You can start with what Gavin wrote on Neutralizing a 51% attack. It'd be particularly good to think through how to make these alternate mechanisms work with SPV clients, yet remain low-overhead. With 1MB blocks it's feasible, if expensive and inconvenient, to switch everyone over to full clients, but with larger blocksizes that's no longer an option so solutions must still provide SPV clients security.

Remember that having alternatives can act as a strong disincentive to any attacker, simply because they'll know that all their hard work attacking Bitcoin will go to waste. Just creating some toy implementations of alternatives as alt-chains to explore the trade-offs is valuable even if you don't ever expect them to be added to Bitcoin itself.

[go1111111]

The original thread (https://bitcointalk.org/index.php?topic=157141.0) is very interesting (most relevant content is on pages 1, 10, and 11), but is now extremely old.

Have there been any new ideas (since April 2013) about ways to make sure Bitcoin's security is adequately funded after block rewards decrease?

There was a particularly surprising quote from Gavin in the original thread, which Greg pointed out didn't seem justified by anything in the thread:

"I'm 100% convinced that if users of the network want secure transactions they will find a way to pay for them, whether that is assurance contracts or becoming miners themselves."

I'm curious if Gavin still feels that way.

Btw, the main disagreement of the original thread was: Mike Hearn argued that miners adding funds to assurance contracts that they'd later claim would still subsidize the network to the same extent as if all funds were contributed by non-miners. Greg Maxwell, Peter Todd, and TierNolan argued otherwise.

I think this is the clearest argument for why Peter/Greg/TierNolan are right: You can think of network security as being driven by the amount of money that is "up for grabs" for miners to claim by solving blocks and including transactions. Only money coming from outside of the miners themselves creates an incentive for miners to increase their hashing, by adding to the pot of potential profits that will be competed away with increased hashing.

[TierNolan]

You can think of network security as being driven by the amount of money that is "up for grabs" for miners to claim by solving blocks and including transactions. Only money coming from outside of the miners themselves creates an incentive for miners to increase their hashing, by adding to the pot of potential profits that will be competed away with increased hashing.

Exactly.  If all miners have to add 40BTC to a 50BTC assurance transaction,  then the reward per block is really only 10BTC.

The amount of hashing per block would converge on 10BTC worth of hashing per block.  The assurance contact was supposed to push it to 50BTC per block (or more).

Having said that, what traders really want is hashing built on top of their own transaction(s).  If you have a 500BTC transaction, then 6 confirms isn't really enough.  Assuming 25BTC per block, you need at least 20 blocks before the value of the transaction matches the value of the hashing.  It would be recommended to have much more than that (perhaps 10X) so that you can be sure your transaction is "locked-in".

The ideal would be a fee system that allows you pay a certain amount per block and the rest is available for the next block.  The 500BTC guy wants to be able to pay fees for the next 200 ish blocks.

That is not critical though, since those transactions would be rare.  Most traders will want to be able to pay fees for the next 6 blocks, so that their transactions will be complete.

[Gavin Andresen]

There was a particularly surprising quote from Gavin in the original thread, which Greg pointed out didn't seem justified by anything in the thread:

"I'm 100% convinced that if users of the network want secure transactions they will find a way to pay for them, whether that is assurance contracts or becoming miners themselves."

I'm curious if Gavin still feels that way.

I still feel that way.

I believe that if people want a secure network, they will figure out a way of getting it. My justification is the same as my belief that if people want clean, cheap, safe drinking water they will figure out a way of getting it.

I don't claim to know how, and it is very possible the how will offend the sensibilities of either (or both) of the "PRIVACY AT ANY COST!!!!" or "DECENTRALIZATION AT ANY COST!!!!" factions. Just like government regulations and institutions around clean water offend the "INDIVIDUAL LIBERTY AT ANY COST!!!!" faction.

I can imagine a lot of possible futures, from big merchants and exchanges investing in mining to save themselves on transaction fees and ensure that their transactions are confirmed securely, to assurance contracts, to a cartel of miners regulated and funded and licensed as a global public utility.

I hope that last one doesn't happen...

[instagibbs]

Perhaps not a wholly satisfying solution as it breaks "rational" economic theory, but I still think it's quite possible that network security will be funded by altruism and/or -EV games.

I think there's a good chance miners are already mining at a loss as a whole. 

If X million people ran cheap USB ASIC sticks, solo(or close to) minig, at a loss, this would not only "fund" the network but make re-orgs vastly unprofitable outside of large fee sniping.

[amaclin]

My justification is the same as my belief that if people want clean, cheap, safe drinking water they will figure out a way of getting it.

It is impossible.
Decentralized systems take more energy than centralized (per transaction)
Nobody will want pay more in decentralized bitcoin than in centralized fiat/government system.

OK, you have a cup of dirty water.
You can use 2 methods to clean it.
First method costs you 10000 kWh energy and gives you 99.99% clear water.
Second method costs you only 1 kWh and gives you 99.00% (safe for drinking)
Which method is preferable?
 

[Gavin Andresen]

First method costs you 10000 kWh energy and gives you 99.99% clear water.
Second method costs you only 1 kWh and gives you 99.00% (safe for drinking)
Which method is preferable?

That is easy, the first. But that is a straw-man argument.

If the decision is:  costs 1.001 kWh and gives 99.99, versus 1kWh and gives 99%, I might decide the extra purity is worth it.

The "centralized is more efficient" might be theoretically true, but in practice the difference might be so slight it doesn't matter.

Theoretically, it would be more efficient if all of our computing happened in huge data centers located near cheap hydroelectric power.

Practically, though, only some of our computing happens that way (e.g. searching terabytes of data), because it is more convenient for us to carry around powerful little computers and we value that convenience.

[instagibbs]

The "centralized is more efficient" might be theoretically true, but in practice the difference might be so slight it doesn't matter.

Or slight enough that enough people who care about censorship resistant networks will patronize the system enough to keep it secure.

Lots of unknowns at this point. Like Peter said, there is quite a lot of time before this becomes a real concern. If it becomes a concern earlier, it means absolutely no one cares about the project and it's dead.

[amaclin]

The "centralized is more efficient" might be theoretically true, but in practice the difference might be so slight it doesn't matter.

This is petra scandali and it does matter.
In decentralized systems every node have to check everything, so the cost for checking is O ( nodes * txs )

Theoretically, it would be more efficient if all of our computing happened in huge data centers located near cheap hydroelectric power.

Why do we need bitcoin decentralization in such case? Let us put Visa/MC/Feds near the nuclear plant to reduce our expenses

Like Peter said, there is quite a lot of time before this becomes a real concern

Not so much as everyone here thinks. Months... May be weeks.

[Gavin Andresen]

This is petra scandali and it does matter.
In decentralized systems every node have to check everything, so the cost for checking is O ( nodes * txs )

You seem to have a very narrow definition of "decentralized system."

In the future I imagine nodes might probabilistically check a random subset of transactions, and broadcast "this transaction is fraudulent" if they find anything wrong.  If you imagine a million nodes, each fully validating one-in-ten-thousand transactions then you get each transaction validated on average 100 times.

That's not so different from your 'treechains' idea (just simpler and easier to reason about, in my humble opinion).

If you think that hardware costs are going to dominate decentralized-versus-centralized payment network costs, then I think you're wrong. Hardware is cheap, people are expensive.

But all of this is really arguing angels-dancing-on-the-heads-of-pins; we've got years before we have to worry about how to fund network security, and a whole lot of things to work on before then.

[amaclin]

This is petra scandali and it does matter.
In decentralized systems every node have to check everything, so the cost for checking is O ( nodes * txs )

You seem to have a very narrow definition of "decentralized system."

In the future I imagine nodes might probabilistically check a random subset of transactions, and broadcast "this transaction is fraudulent" if they find anything wrong.  If you imagine a million nodes, each fully validating one-in-ten-thousand transactions then you get each transaction validated on average 100 times.

Aaaaaaaand... The total work is O ( nodes * txs )
What are you arguing for?
Bitcoin system natively goes to centralization. Miners do not verify transactions at all.
And at current time we have a dozen of mining pool operated a dozen people.
And a lot of obsolete mining hardware which costs nothing ready to switch on for *any* person who will pay $10.

There is no security in bitcoin now just because there will be no security tomorrow.

[btchris]

In the future I imagine nodes might probabilistically check a random subset of transactions, and broadcast "this transaction is fraudulent" if they find anything wrong.  If you imagine a million nodes, each fully validating one-in-ten-thousand transactions then you get each transaction validated on average 100 times.

Aaaaaaaand... The total work is O ( nodes * txs )

If the number of transactions validated per node is inversely proportional to the number of nodes (even if it's a manually configured constant), we're at O ( txs ).

[amaclin]

In the future I imagine nodes might probabilistically check a random subset of transactions, and broadcast "this transaction is fraudulent" if they find anything wrong.  If you imagine a million nodes, each fully validating one-in-ten-thousand transactions then you get each transaction validated on average 100 times.

Aaaaaaaand... The total work is O ( nodes * txs )

If the number of transactions validated per node is inversely proportional to the number of nodes (even if it's a manually configured constant), we're at O ( txs ).

.....aaaaaaaaand total work for all nodes is O ( nodes * txs )

So, the community have to pay all expenses. And the simpliest way is reducing number of nodes... Down to one. And this is centralized system.

[Cubic Earth]

In the future I imagine nodes might probabilistically check a random subset of transactions, and broadcast "this transaction is fraudulent" if they find anything wrong.  If you imagine a million nodes, each fully validating one-in-ten-thousand transactions then you get each transaction validated on average 100 times.

I think this analysis is exactly correct.  I foresee a consortium of miners and mining pools forming their own backbone network.  Transactions will, in general, be submitted directly to the miner backbone network.  The global mining collective will publish a transaction fee schedule, and will offer a service to guarantee unconfirmed transactions.  Since the collective will consist of almost all the hash power, they will have the ability to reject any block issued by a ‘rouge’ miner, and therefore could actively enforce their guarantee against an unconfirmed transaction being double spent.

The P2P network of full nodes will still have role to play, but it will primarily be in auditing the miners.  Miners have an economic interest in maintaining an audit-able network, since openness itself is a primary feature of bitcoin.  As Gavin suggested, nodes could cooperate in auditing the blockchain.

amaclin - the P2P node network could configure itself as a giant parallel processor, with each node auditing just a tiny fraction of the blockchain.  I am just restating what was already said.  The resulting work load of auditing the blockchain would be: TOTAL WORK = (TXS * NODES)/(NODES * “AUDIT REDUNDANCY”).  Audit Redundancy would be how many times a particular transaction would be checked.  It could be once, it could be 10,000 times.  As you can see, the number of nodes cancels out.  You are correct if you are assuming decentralized and 100% trustlessness, but trustlessness is inherently resource intensive, in computing, and in life in general.  Cooperating with others is a great way to cut down on resource usage.

Another audit function of a full node network would make use of the P2P architecture would be as an alternate channel through which to submit transactions to the mining backbone network.  This functionality would be important.  Suppose the mining network was excluding a particular transaction from their blocks, even though it was valid.  A user could submit a copy of the transaction to the P2P network, in essence publicly shaming the miners, and alerting other users to the problem.

A third audit function of the P2P node network would be as a channel for a wrongly excluded miner to submit a valid block.  A bedrock principle we should expect the mining backbone to adhere to would be to be welcoming and inclusive of any hashpower.  The P2P network could be configured to accept and verify any allegations that the mining backbone was engaging is exclusive activity.

[gmaxwell]

the P2P node network could configure itself as a giant parallel processor,

This cannot be done with the design of Bitcoin today.  I've previously (incompletely) sketched out what would be required, but we're a fair ways away from that. And so far there has been virtually no interest in moving things in a direction to support things like that inside Bitcoin.

With the rest of your post you seem to be describing a closed cartel system for mining--  if we have that, why not dispense with the mining, trust it to keep the ledger... (and call it paypal?). Centralized systems are much more efficient and easier to make reliable. I think Bitcoin's (unique) value derives almost exclusively from not being centralized.

[TierNolan]

The P2P network of full nodes will still have role to play, but it will primarily be in auditing the miners.  Miners have an economic interest in maintaining an audit-able network, since openness itself is a primary feature of bitcoin.  As Gavin suggested, nodes could cooperate in auditing the blockchain.

In that case, the miners' cartel back-bone would have an incentive to delay publishing full blocks for auditing.

A third audit function of the P2P node network would be as a channel for a wrongly excluded miner to submit a valid block.  A bedrock principle we should expect the mining backbone to adhere to would be to be welcoming and inclusive of any hashpower.  The P2P network could be configured to accept and verify any allegations that the mining backbone was engaging is exclusive activity.

How would merchants and users respond if a block was excluded?  In theory, they could blacklist one of the backbone's blocks, but that seems excessive.  Cancelling tx fees would be possible, but would likely just encourage fees to be moved off-chain.

[instagibbs]

So, the community have to pay all expenses. And the simpliest way is reducing number of nodes... Down to one. And this is centralized system.

All or nothing false dichotomies are boring.

[DumbFruit]

There seems to be a misunderstanding that addressing the maximum block-size problem will also address the problem of centralization.

Network Costs
P = NCT₁

Node Costs
P = CT₂

P is the total price for transactions. A fee would be P divided by the size of transactions.
N is the number of nodes.
C is cost of accepting a transaction over time.
T is the time between blocks. (The time is different for the network as a whole versus a node.)

As you can clearly see the problem is actually not that a node doesn't bear the cost of the rest of the network, the problem is that the cost of running a node is higher the longer it takes to find a block, but the fee for a transaction is the average between all blocks. The problem is actually the inverse of what I thought when I started writing this post. The network doesn't tolerate the cost of the node, not the other way around.

In other words; The longer a node takes to get a block the higher his fee needs to be to cover his costs, but users will only pay the fee that the network average seeks in order to run. Because people like to pay less in fees, the price will trend toward the entities that collect blocks more often (And those same entities tend to have lower overhead per transaction.)

I would expect that once inflation stops, transaction fees will not be enough for the vast majority of nodes to stay in operation and even hash power in general could atrophy. The atrophy of hash power could occur because the network as a whole functions fine regardless of the difficulty, so hashing will only be high enough to sufficiently keep competitors away, which is less necessary as the blockchain grows in size. It might also occur because transaction fees must stay low enough to remain competitive in the broader currency market.

So the blocksize limit is necessary to keep the barrier to entry low, but ultimately the driver of centralization is actually the lower overhead of larger, rather than distributed, nodes. Crucially; Their overhead is lower per transaction precisely because they get blocks faster.

A "floor" to centralization is when users decide to start using other currencies due to the perceived threat to security. Since 67% of hashing power is currently controlled by 3 entities, it appears that this floor is very low.

The reason Bitcoin has been able to achieve as much decentralization as it has now is low interest, fairly low market value, and low barrier to entry.

Am I missing something? This post really surprised me as I was writing it out so I expect I may have lost my mind somewhere along the way.

A good indication that this (centralization) is not a Tragedy of the Commons problem, is that the problem of appropriate fee pricing disappears if you can guarantee every node has the same hash-power, and the block-size remains low (Regardless of the number of nodes.). Though the block-size issue itself is a Tragedy of the Commons problem.

[gmaxwell]

I would expect that once inflation stops, transaction fees will not be enough for the vast majority of nodes to stay in operation

Are you missing that the transaction load (and thus cost) is limited by the hard rules of the network, just as the supply of coins is... under the current rules there is no risk of nodes becoming too expensive to run. (I just ask because you used such absolute language in you message).