Topic: Funding network security in the future - page 5. (Read 13334 times)

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.

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.

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

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

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.

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.

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 )

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

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

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.

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.

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?
 

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.

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

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.

The original thread (https://bitcointalksearch.org/topic/funding-of-network-security-with-infinite-block-sizes-157141) 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 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.

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.

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?

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:

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:


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.