Bitcoin Forum
November 19, 2017, 01:00:41 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 3 4 5 6 7 8 9 10 11 »  All
  Print  
Author Topic: Funding of network security with infinite block sizes  (Read 23906 times)
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
March 23, 2013, 10:57:27 PM
 #1

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:

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

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. This leads to a game theoretic problem: all members of a group might be better off if an action were taken, and the members of the group contributed to the cost of the action, but many members of the group may make the perfectly rational decision to let others pay for it, then reap the benefits for free, possibly with the result that no action is taken. The result of this rational game play is lower utility for everyone.

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.
1511096441
Hero Member
*
Offline Offline

Posts: 1511096441

View Profile Personal Message (Offline)

Ignore
1511096441
Reply with quote  #2

1511096441
Report to moderator
1511096441
Hero Member
*
Offline Offline

Posts: 1511096441

View Profile Personal Message (Offline)

Ignore
1511096441
Reply with quote  #2

1511096441
Report to moderator
1511096441
Hero Member
*
Offline Offline

Posts: 1511096441

View Profile Personal Message (Offline)

Ignore
1511096441
Reply with quote  #2

1511096441
Report to moderator
Transactions must be included in a block to be properly completed. When you send a transaction, it is broadcast to miners. Miners can then optionally include it in their next blocks. Miners will be more inclined to include your transaction if it has a transaction fee.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1511096441
Hero Member
*
Offline Offline

Posts: 1511096441

View Profile Personal Message (Offline)

Ignore
1511096441
Reply with quote  #2

1511096441
Report to moderator
paraipan
Legendary
*
Offline Offline

Activity: 924


Firstbits: 1pirata


View Profile WWW
March 23, 2013, 10:58:10 PM
 #2

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?

BTCitcoin: An Idea Worth Saving - Q&A with bitcoins on rugatu.com - Check my rep
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
March 23, 2013, 11:24:14 PM
 #3

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".
misterbigg
Hero Member
*****
Offline Offline

Activity: 924


GET IN - Smart Ticket Protocol - Live in market!


View Profile
March 23, 2013, 11:49:26 PM
 #4

why not enact a percentage fee, similar to what we have now with the banking system, on Bitcoin?

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

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.

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.


               ████
             ███  ███
           ████     ███
         ███  ███    ███
       ████     ███    ███
     ███  ███     ███    ███
   ████     ███     ███   ██
 ███  ███     █████████████████
███     ███     ███           ██
 ███      ███     ██          ██
   ███      ██████████      ███
     ███      ██████      ███
       ███      ██      ███
         ███          ███
           ███      ███
             ███  ███
               ████

GUTS
    ███
███
███
███
███
███
███
███
███
███
███
███
███
███
   
smart-ticket protocol for events
live product with market traction!
    ███
███
███
███
███
███
███
███
███
███
███
███
███
███
   
  BTC ANN
  WEBSITE
  BLOG
   
  SANDBOX
  WHITEPAPER
  BOUNTY
   
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2338



View Profile
March 24, 2013, 12:35:21 AM
 #5



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

Bitcoin will not be compromised
ShadowOfHarbringer
Legendary
*
Offline Offline

Activity: 1470


Bringing Legendary Har® to you since 1952


View Profile
March 24, 2013, 12:53:08 AM
 #6

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 ?

gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2338



View Profile
March 24, 2013, 01:52:31 AM
 #7

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

Bitcoin will not be compromised
Peter Todd
Legendary
*
expert
Offline Offline

Activity: 1106


View Profile
March 24, 2013, 02:09:31 AM
 #8

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.

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

d'aniel
Sr. Member
****
Offline Offline

Activity: 461


View Profile
March 24, 2013, 04:02:13 AM
 #9

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.
r.willis
Jr. Member
*
Offline Offline

Activity: 42


View Profile
March 24, 2013, 07:12:21 AM
 #10

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?

1GVmS56pvVL7YZA7YqMBXmaDedCoputKuJ BitEN - Bitcoin Erlang Node
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
March 24, 2013, 09:24:15 AM
 #11

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

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.
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2338



View Profile
March 24, 2013, 03:21:01 PM
 #12

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

Bitcoin will not be compromised
TierNolan
Legendary
*
Offline Offline

Activity: 1120


View Profile
March 24, 2013, 05:28:17 PM
 #13

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.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
r.willis
Jr. Member
*
Offline Offline

Activity: 42


View Profile
March 24, 2013, 05:34:28 PM
 #14

because, e.g. under (2) miners can stuff their blocks with 'fake' txn
Than make block depend not on block size, but total fees collected pervious week. Low fees = block too large. High fees = block too small.

1GVmS56pvVL7YZA7YqMBXmaDedCoputKuJ BitEN - Bitcoin Erlang Node
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
March 24, 2013, 06:19:06 PM
 #15

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?"

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?
TierNolan
Legendary
*
Offline Offline

Activity: 1120


View Profile
March 24, 2013, 08:12:44 PM
 #16

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?

Block X+1 also secures your transaction.  You are paying to get your transaction secured with a certain number of hashes.  This may require multiple blocks.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
yordan
Newbie
*
Offline Offline

Activity: 14


View Profile
March 25, 2013, 04:52:24 PM
 #17

OK clearly some creative solutions might be needed in the interim, that's granted.  But, when and if Bitcoin achieves a really wide level of adoption - let's say a Facebook level - and of course the effects of Moore's law - what if the client was re-writen to require everybody that's running it to do a little mining?  I'm not a mathematician but I bet there is one on the forum that can tell if this is viable...  Let's just say Bitcoin has a billion users and each and every one of them dedicates 10-20% of their CPU power for a couple of hours per day - would that be enough to support the network?
solex
Legendary
*
Offline Offline

Activity: 1078


100 satoshis -> ISO code


View Profile
March 27, 2013, 12:55:07 AM
 #18

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 ?

2. [max] Block size is AUTOMATICALLY calculated...

I agree.
I think option 2. is the simplest and most effective solution to the roadblock of the current fixed limit. I am all for scaling for demand, but scaling for infinity is just going to the opposite extreme.

There is a magic block size around 10MB where the fees market will work properly because they start to exceed the block reward. The existing fee structure, which also allows for some zero-rated transactions, seems to be proving itself in the field as overall fees are slowly increasing anyway. Why don't we let this organic growth continue by employing option 2 soon?

markm
Legendary
*
Offline Offline

Activity: 2002



View Profile WWW
March 27, 2013, 01:20:50 AM
 #19

If it is changeable it can be manipulated and you are basically asking the wolves and sheep to vote, using the sharpness of their teeth as the value of their votes...

You might as well just decide outright mining is something only first world nations and fortune ten or fortune 25 or so companies should be able to afford, maybe with a few telecom corps that own lots of cable even without being in the fortune 25.

Heck having the governments do it makes a lot of sense to a lot of companies maybe, as it puts the cost onto the taxpayers instead of having to pay it directly themselves... Since that would increase government control over the money maybe politicians would agree with that...

Unlimited basically means who ever wins the next world war or world currency war controls a monopoly on it... and invites that war to please commence...

-MarkM-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
TierNolan
Legendary
*
Offline Offline

Activity: 1120


View Profile
March 27, 2013, 09:57:20 AM
 #20

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 ?

Any change to the rules needs to have potential exploits considered.  If you change the rules of the game, then you end up with a different result.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
Pages: [1] 2 3 4 5 6 7 8 9 10 11 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!