Topic: Funding of network security with infinite block sizes - page 11. (Read 24563 times)

It's not really altruism, it's a cost of business. If you're a Bitcoin using business, you clearly need mining to happen and it's OK for that to have some costs, you just don't want your costs to be higher than your competitors as otherwise you'd be at a disadvantage.

I'd imagined that for most businesses they'd just constantly take part in the contracts rather than try to match up pledges with pending payments precisely. Even if you try to only take part when there's an inbound payment, why would you pledge for block X+1 instead of the same block in which your transaction occurs?

Than make block depend not on block size, but total fees collected pervious week. Low fees = block too large. High fees = block too small.

If the system requires a hard-fork, you could just directly add it to the rules.

For example, a transaction could have specify a fee and also how much the payer is willing to pay per THash.

So, if a transaction had 1BTC in fees and set the constant to 0.1 BTC/THash, then collecting the fees requires that you add proof of work on top of the transaction.

Block X (0.3 THash):
- transaction included
- fee = 0.3
- remaining = 0.7

Block X+1 (0.3 THash):
- fee = 0.3
- remaining = 0.4

Block X+2 (0.25 THash - difficulty change):
- fee = 0.25
- remaining = 0.15

Block X+3 (0.25 THash):
- fee = 0.15 (only 0.15 left)
- remaining = 0

This allows a user to spread their fee out over the next few blocks.  Also, it is effectively an assurance contract, they pay 1BTC and it is collected by miners securing the transaction with 1BTC / 0.1 BTC/THash = 10THash.

The could be a limit to how many blocks the fee can be paid forward.

No. This works with high probability with minorities of hashpower for shallow depth if you're talking about shallow burrying, I should have been more clear.

The concern I was trying to highlight is that the separate transaction is just as redeemable if the txns you care about are in the chain or not, so using something like this to secure particular transactions doesn't seem to work until the particular transactions are already secured. So I'm having trouble understanding the motivation the people paying the bond.  "Say I'm an altruist that wants to convince his employer to fund Bitcoin network security, how do I convince my boss that this is a good thing to spend money on?"

Isn't this just a complicated way of saying, "if the majority hashpower is dishonest, then ..."? Bitcoin has always assumed that the majority hashpower follows the rules of the system, changing that so you can effectively buy it on demand with fees does indeed break things, but then (to quote Satoshi), that is a point I already concede.

I think block size is limited not to drive miner's profits up, but to protect network from malicious miners generating large blocks with tx spam.
There need not be limit for block size as network-wide rule in the future, each miner can deside for himself where his limit will be. So, we will have open market and it will regulate itself.
Again, without fees, how tx flood protection will work?

With large blocks supporting say 2000 tps, if 20% of transactors "do their part" and pay an economically insignificant $0.01 fee - way more than enough to cover the microcent cost of the actual transaction - then this would add up to $2400 per block in mining fees.  Currently we've got about a $1500 block reward.

So if the optimal hash rate scales sub-linearly with the transaction rate, then it strikes me that if demand permits scaling up of block sizes, then relying on social pressure and client software defaults to yield lots of individually economically insignificant fees is also a solution to the problem of funding of network security.

With regard to how we will paying miners to keep the network secure, restricting the blocksize isn't an alternative to assurance contracts, it's something you can do in addition to assurance contracts. Thus if one method fails we have the other as an alternative. Unlimited blocksizes on the other hand leave us with just the untested mechanism of assurance contracts, and no backup option.

I dunno about you, but when it comes to the technology keeping a good chunk of my wealth secure, I happen to like redundancy.


EDIT: Having said that, don't get the impression I think assurance contracts are a bad idea. I'd encourage you to start a discussion about making OP_RETURN, possibly followed by a small amount of data, IsStandard()

Both of these cases reduce to "miners choose" (because, e.g. under (2) miners can stuff their blocks with 'fake' txn). Miners choose is problematic for many reasons (discussed in detail in many other threads), but this thread is not about the block size, it's about how you can fund miners in ways other that using transaction fees to compete for limited space in blocks since thats not available if the size is not limited. It would be helpful to not knock this thread offtopic. The alternative funding question is interesting regardless of what happens with the block size.

Is this problem of block size really so complex ? Maybe you are all overcomplicating simple things.

Can't it be solved by using one of following ways ?:

1. Miners VOTE for the next block size every X blocks, using special transactions, extra data put in previously mined blocks or whatever OR
2. Block size is AUTOMATICALLY calculated every Y blocks using some relatively simple algo (like basing on how full previous blocks were) ?

Why is this debacle so long and painful ? Maybe we should do one of these and if it doesn't work, try the next in the row ?

A transaction pays me 1000 BTC in block X.
I want to make sure that payment stays put and isn't reversed.
I contribute to an assurance contract for 10 BTC payable in block >=X+1.

The person who paid me announces a conflicting transaction which pays 50 btc in fees, with child transactions locked at X+1,X+2,X+3,X+4 paying 25, 12.5, 6.25, 3.125, etc.

Miners fork at X, the forking chain collects the 100 BTC in treachery award, additionally they collect the 10 BTC assurance contract.

Sufficiently smart mining software that computes the fork to mine on based on expected returns would be automatically complicit in this attack.

I think this description of having the assurance contracts paid by unrelated transactions is vulnerable to something similar to the POS problem ("proof of stake doesn't work because there is nothing at stake"): miners can mine honest chains or dishonest ones, and get paid all the same.


I'm also still not following the incentives here. Say I am one of the minority with special high value transaction security requirements. And I want to spend X on security, it would be more economical for me to just perform my own mining.. at least then I can be sure my expenditure wouldn't fund the mining of a fork which is not in my interest.  Of course, I have no particular incentive to mine anyone elses transactions if doing so is costly.... and if there are few such parties you wouldn't expect mining to be well distributed...

There's no certain way to determine which of the outputs are the part being spent versus what is being returned as change.


The proposal is to replace variable transaction fees (there always needs to be a minimum fee, to prevent relay spam) by rewarding miners with assurance contract payouts? This sounds very interesting.

Should one of the goals of reward system be to make sure that the hash rate is never decreasing? What if the businesses that provide the bulk of the financing of assurance contracts go bankrupt? The network could experience a significant reduction in hash rate; Miners at the margin of profitability would take their hardware offline. All this offline hardware could flood the secondary market, driving the cost of the equipment down, and cause a "hardware deflationary spiral". Then the network could be vulnerable to attack. Once mining hardware is produced, it is always "out there" even if it isn't active. So idle equipment might considered a threat; Hence, no system should allow for hash rate to drop suddenly.

It seems that a system of assurance contracts would also be susceptible to hysteresis. You even gave an example of it, that merchants would start to notice double spends and bump up the total value of their contracts accordingly. Shouldn't any system of rewards err on the side of always having too much hashing power instead of sometimes having too little?

Liberating the block size limit (assuming no propagation issues) is appealing in the context of assurance contracts because the economic interests of miners are aligned with those who have the greatest need for security but it seems to be a fragile manual process that involves a lot of subjective measure.

You meant why not enact a percentage fee, right?

The argument is that unless there is a hard block size limit, miners are incentivised to include any transaction no matter how small its fee because the cost of doing so is practically zero (less than a microdollar, according to Gavins calculations). Therefore if a bunch of transactions stack up in the memory pool that pay a smaller percentage than "normal", some miner will include them anyway because it costs nothing to do so and maximizes short term profit. Hence, you get a race to the bottom and you need some kind of hard network rule saying you can't do that. We already have one in the form of block byte size, so the debate becomes "let's keep the size limit" vs "let's remove it".

Interesting, now were getting somewhere.

I disagree with one of your points though, why enact a percentage fee similar to what we have now with the banking system, on Bitcoin?

Note: I have moved this post back from its wiki page because Peter Todd repeatedly replaced it with a completely different document. Please update any links to point to this forum thread.

One open question is how will funding of network security (mining) work if there's no competition for block space. If funding for proof of work comes from fees attached to transactions and the fees are motivated by scarcity of block space, then the funding mechanism is clear, though whether it will achieve "enough" funding is not.

In a world where block sizes are always large enough to meet demand for space, we can fund mining using per-block assurance contracts. From Wikipedia:


This describes network security with large block sizes. Everyone needs mining to be done, but nobody wants to be the one who pays for it given that everyone else will get the benefits for free.

As described on the contracts wiki page, an assurance contract is one in which an entrepreneur says "I will pay X towards the cost of a public good, but only if other people chip in enough to reach Y (the cost of providing the good)". If not enough people pledge money, the contract does not complete and nobody pays anything. This mechanism has a proven track record of funding public goods, mostly obviously via Kickstarter.

What is the target?

We need to figure out what "enough" mining means. This is related to the maximum time-value of transactions on the network. For micropayments, you don't need a whole lot of mining to protect all of them because the value of reversing them is very low, and any given attacker isn't trying to reverse all transactions but only the one for their own payment (they can't reverse arbitrary transactions). If you have very high value transactions where the receivers are willing to wait six months then you also don't need a whole lot. If you have very high value transactions that are occurring only between people/entities who trust each other, again, don't need much mining. That might sound unrealistic, but once you go above a certain level transactions almost always take place between people who know and can find each other - think about billion dollar business deals, etc. You don't need miners to ensure that won't be reversed. You just need a functioning legal system.

The type of transaction that's most tricky to secure are kind of middle of the road transactions - not billion dollar business deals, not micropayments but the ones where some real value is moving and it's not worth enough to sue the other side if something goes wrong. If there is enough mining to secure this kind of transaction, then there's enough for the other kinds too. There should be a lot of these, and there should also be a lot of participants.

For an assurance contract to work, do you need everyone who benefits to be a participant? No, some freeloading is OK, as long as those freeloaders weren't going to contribute anyway. Let's imagine that 200 major Bitcoin participants get together and form an assurance contract that funds 10 terahashes of mining (numbers are arbitrary). Does their agreement break if 200,000 users then make 500,000 micropayments? Not really - those micropayments hardly need any mining to be secure and those users weren't going to pay for 10 Thash no matter what, not even collectively. There's no downside to them being able to benefit from the extra mining you pay for and indeed, there may be indirect upsides (your Bitcoins become more valuable because they have greater utility).

Implementation

Implementation can be done effectively via the introduction of a new network rule. It says that money spent to an output that contains an unspendable script can be claimed as fees. We're already introducing the idea of OP_RETURN outputs that simply result in insta-pruning of that output, as it's provably unspendable. Allowing that value to be claimed as fees is a hard-forking rule change, but it's also a relatively straightforward one (the alternative is to have the money be destroyed ... which is bad), and we need to hard fork to increase the block size anyway. Once this is done, we can have a separate P2P broadcast network in which participants broadcast pledges. The pledge is an invalid transaction that takes X coins with a SIGHASH_ANYONECANPAY signature and then re-allocates it to an unspendable output of Y coins, where Y > X. X is the pledge and Y is the target, of course. Peers listen and when they have seen enough pledges to sum up to a value of greater than Y, they just combine them to make the tx valid and broadcast it on the regular Bitcoin network. Peers can do this in parallel - there's a chance of naturally occurring double spends but rules on how to construct the contract out of the pledges can probably reduce that to a trivial level.

Note that it is possible to do spend-to-fee assurance contracts without the new rule, but it'd be complicated and involve a multi-round protocol in which people first announce they want to pledge an output, then someone has to build a template transaction based on all the announcements, then the group signs it in parallel. It can be done but it's messier.

What are X and Y set to? That depends on what the participants want. It'd be nice to find economic research on the case where the public good in question is continuous, but I don't know of any at the moment. I think it'd likely work like this - merchants that have noticed that they start seeing double spends when network speed drops below 5 THash/sec would clearly be targeting that amount and no more. Other merchants might only care about 1 Thash/sec. In that case, the first class of merchants can set their Y to 1 Thash and just broadcast multiple independent contracts, this means there is a chance that they'll get less than what they wanted (which weakens the definition of the target) but there's more of a chance of the contracts completing. At any rate, they would reduce their pledge size as well for each contract, so they aren't exposing themselves to freeloaders at any greater level.

For X, I imagine that if you start from a steady state your goal is to lower it as much as possible without stopping the contracts from completing entirely. One way is to lower your pledge and see how fast the contract completes - if the contract doesn't complete within your required time limit, you can just (anonymously) broadcast a second pledge to make it back to what you were previously pledging. But other players don't know you might do that.

In a healthy system I'd expect there to be many independent, overlapping contracts being formed. They're simple to construct so doing one per block is reasonable.

Conclusion

Obviously whilst there are many participants with different ideas about what network speed is "enough", with only one chain there can only be one speed. People with extreme needs would end up not being able to use the block chain for their security and would have to find alternative arrangements, or just accept that they'd be subsidising the activities of others who can tolerate lower security.

I think the next piece of work needed to explore this idea is searching the literature for studies of assurance contracts for continuous public goods, as the primary difference between what this scheme would do and proven models like Kickstarter is the need for group consensus on what "enough" mining means.

That said, I note that the alternative proposal (restrict block size and charge fees to get in) doesn't even try to answer the question of how much mining is enough. It's just assumed that some arbitrary byte limit would result in demand exceeding supply to the level that mining is well funded. The problem being that limiting blocks by physical size doesn't jive with the fact that they move abstract value - if anything, for such a scheme to work, block sizes should be limited by satoshis transferred. Otherwise you could get a bunch of very high value transactions that end up with tiny fees because that's all that's necessary to get into the block, as lower value transactions have long since given up on the system and gone elsewhere.