Funding of network security with infinite block sizes

[Stampbit]

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.

I feel that just THIS makes me strong bull again ..



friedcat presented USB powered mini ASIC running 300MH/sec. That's what I call DECENTRALIZATION.

This looks great. Thread for interested lurkers: https://bitcointalk.org/index.php?topic=99497.3180

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

[1714825819]

1714825819

[1714825819]

1714825819

[1714825819]

1714825819

[johnyj]

I understand the "lets engineer for the far future" ... but, frankly, I think too much of that is dumb. Successful projects and products engineer for the next year or two, and re-engineer when they run into issues.

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

[Mike Hearn]

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.

[TierNolan]

Making the blocksize large as a solution will cripple Bitcoin with centralization and lack of anonymity.

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 <header> and nonce <nonce>"
<time1 passes>
Server sends: "Block is stale: stop hashing, no further credit will be given for meeting target"
<time2 passes>
Server sends: "New block generated: please hash against this header <header> and nonce <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.

[gmaxwell]

Maybe the answer will be "validation pools" like we have mining pools today, where people cooperate to validate part of the chain (bloom filters, DHTs, mumble mumble....). Maybe hardware will just keep up.

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.

sigh.  Mike explained how that is likely to be avoided. 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

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?

or becoming miners themselves.

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.

[gmaxwell]

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

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.

[TierNolan]

I think you're confusing miners with people who sell their computing power to miners.

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?

[Peter Todd]

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

[TierNolan]

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.

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.

[Mike Hearn]

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 <X then they'll only contribute to contracts with a target of X, but for a different participant if Bitcoin becomes useless at block reward < Y and Y < X then, as you note, they can pledge the same output to both contracts and see which wins.

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

[Peter Todd]

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.

[TierNolan]

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.

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.

Code:

If block_height < X + 100
 pay <assurance contract input>
else
 pay <some address>

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.

[Stampbit]

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?

[TierNolan]

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?

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

[Mike Hearn]

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.