Topic: Funding of network security with infinite block sizes (Read 24568 times)

I moved the content back to the forum post and erased the contents of the wiki page, as I said I would.

Peter, you have wasted my time with this immature edit war. I had to go through and convert the formatting back to bbcode after converting the original to wiki syntax. ripper234 posted a link to the wiki page to reddit after double-checking that it was the same post he read - you have now invalidated that link and wasted his time too.

You should have put your own document on a new page and opened a new discussion for it instead. This is exceptionally poor form and I think you should take a step back for a while, then come back to these debates when you aren't going to simply irritate people who have been around a lot longer than you.

TierNolan, yes, it is the same. A fee is a "donation" to the winner of the next block, the competition to claim those "donations" is what incentivises mining. If a miner is willing to take part at a certain difficulty level and claim contracts that didn't yet reach their target, then he is simply earning less than if the contract had reached its target. That exerts a downwards pressure because people see they don't need to set the targets so high and is a useful feedback mechanism to the market. I'm not sure why you're getting so hung up on this. The people who took part in the contract got what they wanted because the next block was mined.

Merchants mostly.  Also, the transaction isn't actually that hard.  There could be a few standard transactions, and you can add inputs to them.

From what im reading on here about assurance contracts, this seems like alot of effort on the part of users to establish them. Who exactly is this targeted towards?

No, they aren't.  It is completely different in terms of incentives to mine.

If I create a contract where I pay in 0.01 BTC and it pays out 5BTC in fees and publish it, then any miner who completes a block can claim the 0.01 money.

It is basically a donation to the winner of next block.

The reason is that the miner can keep his 49.99BTC donation private.  Only his block can win his 49.99, so he isn't pledging it.

The full transaction, with the full set input payment, must be available to all miners.

So, the transaction should be locked until block X.  Pledgers can then cancel their transactions at block X - N, if it hasn't been incorporated into any block.

An input lock time would help here.  If scripts had an OP_BLOCK_HEIGHT code, then you could implement this directly into the script.


This would allow someone lock the input for 100 blocks but still get the refund after that.

What is needed is that the transaction gets locked in at block X - N and but is given to the miner who mines block X.

Mike: please explain how what you are proposing is an assurance contract, by the standard definition of what an assurance contract is (http://en.wikipedia.org/wiki/Assurance_contract) without the fixes to your method that I proposed. (nLockTime and locked outputs)

In any case, reverted. The wiki needs a page describing how network security is funded, and that includes all the available methods, present and future.

retep, I rolled back your wiki page rewrite. If you do that again I will delete the page and move its contents back to my original post.

I didn't move what I wrote to the wiki in order for you to delete it and make the resulting debate in this thread impossible to follow, especially not for you to replace it with completely different material. I moved it there so it would be easier to find and link to, and so useful edits like those from ripper234 could be made easier. Please do fetch your content from the revision history, put it on a different page and link to it from your own post.

A miner completing the contract with their own money makes no difference - they are taking part like anyone else. Effectively, they are subsidising mining and sending a market signal that the contract target was too high. The next contracts that come along will likely lower the target because there are miners willing to solve blocks at the same difficulty for less money.

Being able to claim multiple contracts in the same block isn't an issue either, it's how I'd expect it to work. Nothing says there has to be One True Contract for each block. Indeed there probably shoudn't be because different participants will have different ideas of how much mining they want done - if Bitcoin is useless to a participant at a block reward
On the rest, very briefly because I am long since tired of these pointless debates:

We're talking about infinite block LIMITS not sizes.

The contracts are not acts of charity, they are a cost of business.

They don't want to do pooled mining themselves because it means they don't get the club-good aspect of an assurance contract (they mine and others benefit from their expense even if they don't contribute). But who knows, perhaps some will.

Participants know how much mining is required because they will let it slowly fall until they start seeing unacceptable levels of double spending. I have always said this, for years now, in many threads on this forum - the long term equilibrium is not likely to be "no double spends ever" because in reality many merchants can/do tolerate some level of double spending, and that may be more efficient than extra mining, so the long term equilibrium could be somewhere else. We see this already with shops that accept 0-confirmed transactions. Bitcoin cannot be compared to alt coins because Bitcoin is being used to protect real value in real economic activity, something no alt coin ever achieved (though maybe litecoin is on its way).

No, it means that the effective fee per block is lower.  The assurance contract is to ensure that all miners mining for the block get a marginal X BTC reward.  "I will donate to the reward, as long as the total reward exceeds 50BTC".

Another problem is that a miner can claim 2 reward contract in the same block.  nLock could be used to solve that.  You pledge to 6 transactions, each with +1 on the lock time.  This way you can support hashing on the next 6 blocks.

A pledger could pledge the same coin to lots of contracts so that only 1 needs to win so that the miners get rewarded.  That would prevent cancelling the pledge though.

Re-wrote the wiki page with corrections, as well as expanded on the material to discuss the issue in general.

OK, it is a terminology thing.  So, "miners" have nothing to do with hashing?  Is there a term for people who rent out their hashing power?

I think you're confusing miners with people who sell their computing power to miners. Someone who has no knowledge or interest of the integrity of the blocks they are producing are little more miners in the language we'd use to describe the security properties of the system than AMD or a random electric company is— the only difference is that they potentially have a kill switch which they could use long after its too late.

Maybe! I hope so too.

But I also think the burden of proof when arguing to degrade security should be to show that some compensating thing exists and works, not arguing that _maybe_ it will come into existence.   It's hard to put the loss of trust genie back into the bottle: "Well we haven't been totally compromised... yet". But once we have been, it's too late.  (This has now been pretty thoroughly demonstrated by altcoins: They don't achieve adequate security, someone comes in and reorgs them and then they're dead)

If it's obvious that size X will be safe, then increasing the acceptable size to ~X should be pretty straight forward, and if people can't be convinced that its safe— it ought not be increased.


I took a couple days to wait and contemplate this and took time to reread the thread and the other responses...  Because I can't figure out where Mike did this, or why you believe it.

What Mike pointed out is that people can create additional transactions that give away funds to miners.  They can be redeemed by _any_ miner— ones mining an honest chain or a dishonest one that reverses the current consensus, one where difficulty is increasing or decreasing, one which includes one set of transactions or another.   Mike doesn't explain why Patron organizations will perform these acts of charity as opposed to sitting back and hoping that other people perform them,  he doesn't explain why people who want to fund security in this model wouldn't just mine themselves (and then at least they know their resources aren't being spent on a chain that rips them off), he doesn't explain how in this CommunistMinerUtopia the Patrons know how much security is actually required except by getting attacked (something no alt-chain has survived),  he doesn't explain how the Patrons can afford to make offerings which are sufficiently large to achieve adequate POW when— with "infinite" blocks— _honest_ miner's have "infinite" cost in just processing/validating/transmitting blocks.

He even alleges that "There's no downside to [500,000 micropayments] being able to benefit", when there are substantial costs to transmitting, validating, and storing additional transactions— and that these costs make it more costly for all the honest participants to enforce the honesty of the system.  Perhaps the cost is worthwhile, but I don't think we can have a good discussion when they're falsely set to zero.


In short— Mike hasn't answered the question at all. He uses a lot of words (pot kettle black, I know) to point out that people can make additional transactions for the pure purpose of jointly giving coin to miners and then basically says that people will do it because it's a public good.

The joint mechanism itself is a distraction: In the proposed protocol the miner can just add his own outputs to the contract and snarf up any amounts offered, so it would appear to buy nothing— just using plain transaction fees at least has the advantage that if the txn in question falls out of the chain the miner doesn't get paid.

If something being a public good is sufficient then why doesn't it work for altcoins?  How can you be 100% confident in something which has demonstrably failed to protect other cryptocoins?

I agree that transactors becoming miners actually works in preserving the interests of people making transactions... Mike argues that assurance bond payments would be provided by Patrons who had major interests in the security of the coin, presumably under the miners themselves argument these same parties would be the only miners and validators for the "infinite block case", but then the result is not well distributed the control of the system would rest in a few large hands (presumably nation-states). In that case perhaps mutual distrust keeps the POW from racing to the bottom, but that conclusion has other problems.

The argument here is evaporation cooling.  Low bandwidth miners spend more of their 10 minutes downloading.  If it takes 1 extra minute to download the new block, then the low bandwidth miners are 10% less efficient.  They go bankrupt and the block size increases again, and then another layer dies, until just a core remains.

However, "miners" are really validators/block creators on the one hand and hashers on the other.

The pool administrators are the validators.  The group that does the hashing is separate.

So, what you are worried about is a pool operator or group of them getting > 50% control.  In that case, the people doing the hashing could direct their support to a different pool.

Also, even if they were purely profit orientated, they could pool hop.  For the first minute, they could direct their power at the high bandwidth pool.  Once then 2nd pool had a new block generated, they could switch to that.  This would allow support for the outsider pool, with little negative effect to the person running the hashing system.

The pool connection protocol should probably have something like that anyway.

Server sends: "New block generated: please hash against this header

and nonce "

Server sends: "Block is stale: stop hashing, no further credit will be given for meeting target"

Server sends: "New block generated: please hash against this header

and nonce "

I think at the moment, the server can say that a new block has been found, but that doesn't tell the hashing software to halt hashing.  It just gets it to ask for a new header to hash.

A hasher could connect to multiple pools and set his software to prioritize certain pools. 

If the margins got tight enough, hashing engines might be put into standby for a few seconds while even the fastest pool has no new block available.  However, if you were connected to the winning pool, then they should be very fast, since no verification of the new block is required.

If a miner completes a contract with their own funds it doesn't make any difference, they're just taking part as normal and mining for less money.

I guess when Satoshi laid out the framework for bitcoin, he looked forward for at least 100 years

Of course the fee problem will only appear after 100 years, enough time to discuss

If that USB ASIC also includes FIOS then i'd call it decentralization too.

Arguably OT, but still important to the thrust of the OP and much of the debate where network security = decentralization.
Astounding developments like this will drive forward Bitcoin's success.

It is an assurance contact.  You say "Pay the miner who includes this transaction 100BTC, signed by me for 10BTC, allow extra signatures".  This is an invalid transaction since you haven't included enough money.

However, if others create more transactions, you end up with something like

Pay the miner who includes this transaction 100BTC, signed by me for 10BTC, allow extra signatures
Pay the miner who includes this transaction 100BTC, signed by person2 for 60BTC, allow extra signatures
Pay the miner who includes this transaction 100BTC, signed by person3 for 30BTC, allow extra signatures

These can be combined, since they are identical except for the signatures to give:

Pay the miner who includes this transaction 100BTC, signed by me for 10BTC, signed by person2 for 60BTC, signed by person3 for 30BTC, allow extra signatures

This is only possible if you explicitly allow extra signatures.  

The final transaction is valid, so can be submitted to the main network.  If a miner includes the transaction in the block, they get 100BTC.

The idea is that lots of people could add a few BTC.  However, it is only valid if the total is 100BTC (or more).

Hi guys, being not that deep into bitcoin I was trying to make some sense from Mike's proposal. I wrote a comment on reddit describing it to normal people as best as I could. But I'm still not sure if it's more or less right. It would be nice if someone translated the proposal to more accessible language, as the way we will fund the network in the future is pretty important, and more people should know what are the options.

Yeah, there is a risk, esp if the amount you add it very high.

A similar situation was discussed in another thread (ish).

The current rule is mine the longest chain.  However, if a miner included a payment to true in the block, then it would encourage other miners to build on his block.

If the chain was

A -> B -> C ->

but B has a large payment to true and C doesn't, then miners would be encouraged to keep mining against B, rather than accept the new block. 

This means that you have a tradeoff.  If you create C' and it pays a lot of the reward from B onward to true, then you weaken the incentive.

An equilibrium would set it where there is an incentive to include some payment to true.  This means that tx fees are effectively smeared.

I assumed there was basically 2 strategies

1) Mine against the longest chain
2) Mine against one of the top-2 blocks, whichever pays the highest to true

Depending on the payout for the top-2 blocks, neither strategy wins outright, a certain fraction will follow each of them.


You can only spend your own input.  All other inputs would still be valid.  In effect, all participants would have to cancel.

It does offer protection for those who actually care.  The miner would have to publish the tx a few days (or hours) before the deadline, so he couldn't add it to his block.


The only thing that would accomplish is to reduce the total, since the inputs from anyone else who contributed would still be valid.


What would be good would be the timestamping thing.  For example, you a hash of the tx must be included at least 10 blocks previously.

All full nodes you are connected to.  They will verify the block and if it is ok, forward it to all full nodes they are connect to.  However, if they receive the block a 2nd (or later) time, they don't forward it.

This sends the block to all nodes on the network.  However, large blocks will propagate more slowly.