Topic: Slowing down block propagation (Read 3677 times)

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.

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.

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!

Greg, does Meni's proposal (https://bitcointalksearch.org/topic/elastic-block-cap-with-rollover-penalties-1078521) which has a penalty formula that does not include the transaction fees solve this problem?

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.

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. 

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.

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.

Yes, I meant revenue, not profit.

I need to stop saying "profit" entirely, even when I mean "profit"-- it has different meanings for economists and ordinary people.

This is a good point.  Adjusting the difficulty is a better solution, however this seems to undermine Bitcoin’s core longest chain rule security mechanism, which is too much for a peripheral mining incentives issue.


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

You may be right that more transactions will increase the BTC to fiat exchange rates and that two of the variables in that equation increase, however if the fee falls then overall mining revenue can fall.  This is possible and merely depends of the elasticity of demand.

In economic theory, there is the well known monopoly idea where supply is constrained to increase profits.  This is not ideal, but it may be possible.


Source: http://en.wikipedia.org/wiki/Monopoly_profit


You are correct that artificially implementing production quotas to increase prices is normally a bad idea in almost all markets.  In the market for Bitcoin transaction fees, which has many unique characteristics in my view, implementing this is not perfect either and is likely to cause problems.  However there is no perfect solution and I think an arbitrary quota is something worth seriously considering.  Please don’t misrepresent what I am saying as being in favour of a 1 MB limit, as I am not.

If the marginal cost of adding additional transactions to blocks is effectively zero, then that’s a pretty unique situation.  If the market is competitive then price = marginal costs, which means miners profit will tend to zero.  It is not impossible that imposing this quota will increase miners profit from zero.  In my view a differential marginal cost of adding transactions to blocks for different miners, is desirable, that way one can have a cost curve dynamic which makes the market more robust.  If the marginal cost of adding transactions to blocks is uniform across all miners, I think we may run into some problems.

Why do we need transaction relayers? What vital function do they provide?

Miners need to be connected to each other, and to transaction creators (individual users, exchanges, merchants, online wallets, etc).

And transaction creators need to be able to connect to miners, but it seems to me transaction fees should certainly be enough incentive for miners to arrange for there to be plenty of opportunity for transaction creators to send them fee-paying transactions (it's cheap to run nodes that have tens of thousands of incoming connection slots).

my idea was that the first full node which sees the transaction does (instead of relaying the transaction) relays his contact info. the miner would need to contact one of this nodes in order to get the real transaction.

only thing i am unsure about is how the miner can proof to that node that he will really try to add the node-paying-transaction to the block.

i think paying only the first node is not bad

One cannot gain ground by implementing a solution that's susceptible to the same conditions the solution was meant to solve.

We pay ppl for mining a block and they prove this with a smaller number after a double round of sha256 than anyone else.  How do TX relayers get paid?  I see one of two possibilities.

1. It's advantageous to append to the list of really proofs because you'll be paid more for not discarding proofs supplied by others.
2. The relayers will discard all other proofs and forward the TX directly to the miners with just them being paid.  The miner will strip off that proof and supply their own.

In the case of 1, miners will generate a set of proofs as long as they can...  Even if they have to supply millions of watts to dedicated ASIC chips to do so.

I don't see how one intends to 'prove' to the blockchain that they relayed a transaction, without someone else being able to undo their efforts.  Explain this shit to me.

The best I could come up if is proof by guided tour, but then who pays the tour guides and how do we pay the payers of the guides?  It's an endless loop.

i dont want any artificial cap. in fact i want an unlimited blocksize (but i think your proposal is ok).

i just think that we need an incentive for a miner not to put any transaction in a block but only those which pay a high enough to cover his(!) costs.

my reasoning:
 - good distribution of bitcoin nodes through various asn (which also means countries which dont have a very good connection or cheap vps's as we are used to)
 - higher costs for transaction spammers

i do just fear (as explained above) that without any incentive for smaller blocks miners will take any fee paying transaction.

i am not really sure about the consequences of 1BLT/headers first. some people say that its a O(1) operation others say it isnt

if it isnt: all is fine, because i feel that this is incentive enough.

(i know O-notation does not really fit bandwith; but i am sure you'll get what i mean).

Why do you want miners to have an incentive to make smaller blocks?

Smaller blocks means fewer transactions, so fewer opportunities to collect fees, so less profit.

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

Experience (and common sense) says that more usage of Bitcoin means a higher btc-to-fiat exchange rate, so if you want to maximize miner's fee revenue then increasing the number of transactions is the obvious way to do it.

If you think that putting an artificial cap on the number of transactions will increase overall miner profit, then I urge you to find a Real Economist and talk to them about the wisdom of trying to use production quotas to keep prices artificially high.

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.

to me this doesnt sound bad at all.

what i'd love to see is that the additional "lost" fees are somehow distributed to the nodes transmitting the transaction (i dont have an idea how this could be accomplished without cheating though)

i know lost bitcoins are not a real problem, but i still have a bad "feeling" about it.

EDIT:
what about this:
i craft a new transaction with 1btc mining fee
 - some node receives this transaction and signs it.
 - it now relays the following data
     # tx/txouts
     # his own ip/port
     # one of his own addresses
     all signed by his key (not the key of the original txin's)
 - a miner receives multiple versions of this transaction signed by different "first" relay nodes
 - he now contact one of this nodes and ask for the original one
 - same magic needs to be done to make sure the miner is forced to send some fee to the first relay if the block size exceeds 1mb.

I'm not sure that memory pools per different policies will be sufficient. Primarily because each pool will have different policy of accepting zero-fee transactions because the fee will be out-of-band.

Pools should start integrating with other businesses like exchanges or casinos, and then each pool will have material incentive to support the integrated business.

So I'm more thinking a memory pool per different peered mining pool, especially because the number of mining pools should go down.

Anyway, for now it is just another way of counting the proverbial chickens before they hatch.

I know this sounds as bad as the slowing down blocks suggestion.  But an alternative would be to make miners pay higher fees for larger blocks.  An increasing haircut on transaction fees related to block size.  

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

This would create a marginal cost of including more transactions in blocks.  The problem with this might be that the extra marginal cost doesn't differ enough for different miners on the mining cost curve.

No, missing transactions are extractable from the IBLT. 

The rule is that the size of the IBLT must be greater than the difference between the sender and the receiver.  If the memory pool in both nodes is 1% different, then the size of the IBLT needs to be a few percent of the size of block.

If it became popular, then there is an incentive to keep memory pool policies are close to standard as possible.  If they could be kept nearly identical, then the IBLT can be kept very small.

The O(1) scaling assumes that block size can be increased without increasing the total number of differences.  In order to keep the IBLT the same size, if the block size doubles then the fraction of transactions that are different halves.

Miners could maintain a few different memory pools with different policies.  The IBLT would only need to (near) match one of them.