Slowing down block propagation

[Cryddit]

For what it's worth, I have a woolly idea.  Like most of my ideas though, it's got its security issues and it's pretty firmly in Altcoin territory.

Suppose node operators "advertise" their nodes in the block chain (a maximum of once a month) with a tx that has data attached giving their node's unique IP address.  This would be a good thing anyway as a way to help do node discovery when a client comes back on line.

Suppose we have a semi-random number every round - one that's hard to predict far in advance, but which no single miner or reasonably small coalition of miners can determine or choose with any significant degree of freedom.  Maybe we pick a particular 3-bit range of the block ID's provided by each of the last n miners to determine one-third of a bit each - first guy's input determines whether the second guy faces a 75% bias toward 1 or a 75% bias toward zero, second guy's input determines whether the third guy faces an 87% bias toward 1 or an 87% bias toward zero, third guy's input determines whether the bit turns into a definite 1 or definite zero.  Three other miners pick the next bit, rinse repeat.  When it comes down to the last miner, they get to pick a one or zero in the last bit only - but in order to choose against the bias if it didn't just happen that way by accident, they'd have to discard an average of three potentially winning hashes.  

And based on that semi-random number (and simple transformations of it such as by using it as a starting point for an LCG) we pick fifty of the nodes advertised in the most recent month, query them, and if they can show that they've been doing at least *some* mining - six or so orders of magnitude less mining than required for the block target, but some - then they get a small share of the block award for running a node.  

Because it isn't *just* miners who secure the network, it's node operators too.  And it isn't *just* the miners who bear the bandwidth and storage costs, it's node operators too.  And it'd be a good thing (reduce pool influence and the accompanying 51% attack vulnerability) to provide a good incentive for node opeators to do solo mining that didn't require centralization with million-dollar investments, even if the million-dollar investments are going to do the block formation effectively all of the time.  

There are a lot of sybil attacks you'd like to try and avoid here, and DoS attacks related to most means of trying to avoid them.  But if the 'sybil attack' means each sockpuppet runs a node reachable via a different network route, then 'sybil' may not be such a bad thing.

[1714838115]

1714838115

[1714838115]

1714838115

[1714838115]

1714838115

[DeathAndTaxes]

The problem is that simply having an IP address that is accessible or completing a low diff POW doesn't mean you are actually a node.   Proving you are actually a node especially over an extended period of time is a non-trivial problem.

[Cryddit]

The problem is that simply having an IP address that is accessible doesn't mean you are a node.   Proving you are actually a node especially over an extended period of time is a non-trivial problem.

Absolutely true.  And thereby hangs the crux of the problem of motivating people to keep nodes up.

It's far more important that they be reachable via separate network paths, don't all go up and down at the same time like dozens of virtual machines on one server, and don't actively collude to subvert network security.  In fact, it might even be as problematic for security as pool mining. 

[gmaxwell]

For what it's worth, I have a woolly idea.  Like most of my ideas though, it's got its security issues and it's pretty firmly in Altcoin territory.

Suppose node operators "advertise" their nodes in the block chain (a maximum of once a month) with a tx that has data attached giving their node's unique IP address.  This would be a good thing anyway as a way to help do node discovery when a client comes back on line.

Been proposed before, we also looked at using it in p2pool but turned out not to need it there.

I think you're over-complicating it. You can just allow miners to disclose an address message in their blocks, could be them, could be some other node they like. It would give another view of the topology of the network, which would be helpful.

A key observation is that the ordinary non-partitioning security requirements mean that you only need one honest peer (but, sadly, privacy requirements mean you would really prefer no dishonest peers).

Absent authentication in the transport, however, a network attacker can still partition you even if you get node pointers from blocks. This diminishes the potential benefit.

[jonny1000]

e.g. 1MB block 0% haircut, 10MB block 10% haircut, 1000MB block 95% haircut.  Some polynomial could determine the formulae.

Diminishing fees doesn't work in the long run, as fees can be paid out of band. An alternative that has been proposed is adjusting the difficulty, though this only allows small adjustments.

Greg, does Meni's proposal (https://bitcointalk.org/index.php?topic=1078521.0) which has a penalty formula that does not include the transaction fees solve this problem?

[Sergio_Demian_Lerner]

Regarding the original subject of this thread about block propagation. This is a prediction, although I have strong arguments supporting it.

If Bitcoin succeeds, it will go thorough 5 stages:

1. 2009-2014: O(N) propagation (the past stage). The cost of a transaction (in a block) for a miner is bounded by the time it takes to process each transaction and the times it takes to transmit it. When the signature cache was included (and other optimizations), block processing time stopped being a bottleneck.

2. 2015-2016: O(N) propagation (our current stage). The cost of a transaction for a miner is bounded by the time it takes to transmit each transaction (of a block).

3. 2017-2018: O(N) propagation for a multiplicative constant much much lower than in the previous stage (next stage, wrongly called O(1)). Each transaction costs less than 10 bytes of propagation time (the space needed to uniquely identify it), so transactions are really cheap for miners. Better we have a working market for fees during this stage.

4. 2019-2069: O(1) propagation (the real one). Miners mine on top of headers without even having the full transactions contained in them. Miners mine empty blocks until either they give up waiting or they receive the previous transactions. Subsidy is still high, and Bitcoin is very valuable, so the risk of a good header with missing txs is low. Miners connect to each other with reliable backbones and transmit both blocks and transactions. The real cost of a transaction is close to ZERO, so the only defense from spam is a working market for fees and rationality. The cost of a transaction may be bounded by the storage cost in the blockchain, but miners may not even store the full block-chain, and only process the UTXO set.

5. O(?) propagation (50 years from now maybe). Miners cannot mine on top of empty headers anymore because subsidy is too low to have any advantage on doing so. Either all miners form a syndicate, or propagation becomes an issue again.

Enjoy!

[kano]

4. is already done by any pool that uses eloipool code.
It would seem they think that the poorly coded delay between knowing the block has changed and sending out transaction work is an excuse to do that.

[jonny1000]

Miner profit in fiat currency = number of transactions * average transaction fee * btc-to-fiat exchange rate

Should this not be:
Miner revenue in fiat currency = number of transactions * average transaction fee * btc-to-fiat exchange rate?

Yes, I meant revenue, not profit.

Gavin, if you would like to try to maximise miner revenue in fiat currency, which I think is a good idea, will you support Jeff's BIP 100, which will enable miners to vote for the blocksize limit to maximise their long term revenue?  The proposal avoids us debating about price elasticity of demand and instead lets the miners make their own decision, in a market driven way, about how to optimally maximise the parameters in the above equation.