Topic: New paper: Accelerating Bitcoin's Trasaction Processing - page 6. (Read 36280 times)

After some discussion at #bitcoin-wizards (freenode IRC) with Aviv Zohar and several Bitcoin devs, it seems to me that there is an advantage to the current Bitcoin rule for selecting the best chain, over the proposed rule in this new paper.

First note that there is ongoing research by Bitcoin devs to enable lite nodes verify whether txns are valid (link1, link2, link3), which may also allow us to remove the checkpoints in the client because new nodes can be bootstrapped without having to verify the signatures in the entire history, hence the Bitcoin system will be more trust-free.

Consider an attacker who creates many difficulty-1 orphans that extend the genesis block (which requires relatively low PoW effort) and thereby DoS-attacks the other nodes by bloating their local copy of the blockchain with these many orphans. Note that headers-first sync will mitigate this attack somewhat, because the nodes will only fetch and keep the headers of the orphans, but it wouldn't fully mitigate this attack. Right now, Bitcoin is protected from this attack because of the checkpoints, as clients will reject orphans at genesis because of the later checkpoints.

If the checkpoints are removed, I think that Bitcoin can still have anti-DoS mechanisms against this kind of an attack. For example, the most naive anti-DoS protection would be for the node to have some quota and not accept more than certain amount of forks that extend an (old) block, with small risk that it may need to request those rejected blocks later from peers, and waste communication.

So, under the assumption that eliminating checkpoints to have a zero-trust system is a worthy goal, the question is whether we can have anti-DoS protection with the proposed rule for best chain selection of this new paper. Depending on how exactly the nodes will reject blocks that are suspected to be attack-driven, I think that there is a danger that it could cause netsplits and that the network won't re-converge. Even if the network will indeed be convergent, the communication complexity could be significantly greater, as nodes will frequently need to prove to other nodes (who rejected or deleted blocks due to anti-DoS protection) that they have a subtree with a bigger weight?

I think that there are pros/cons to this new proposed rule versus the Bitcoin rule (the complexity needed for lite nodes is probably another disadvantage, and of course there are also significant advantages as discussed in the paper). At this particular moment in time I'd feel more secure to exchange my fiat money for bitcoins than for a cryptocoin that implements the newly proposed chain selection rule But I'm of course open the possibility that the new rule will lead to a system that's more secure overall.

Clearly you have not read the paper.

if a block will be created every second on average, blocks will be generated so fast that it will create huge problems.

the network will not be able to verify the order of the blocks, and it will be impossible to know which chain is the real chain.

the whole reason the block-chain handles transactions is to prevent double spending by abusing lagg that would mess up the order of the transaction, because the network disagrees about which transaction happened first.

There's no way the whole network can confirm a block within a second.

It's an externality. If your logic was right, coal power plants wouldn't exist, but they do.

I suggest that the value of a bitcoin is directly related to the trust in the decentralization of the system.
And the level of trust in Bitcoin is somewhat related to its (de)centralization. The higher the centralization, the lower the value per block.
I don't see any mention of that in your paper about 'centralization incentives'. Shouldn't that be part of the equation?

A practical consideration: Just like Christian Decker and Roger Wattenhofer reported, a 320KB block would take 80 seconds to reach 90% of nodes, or 40 seconds for 50% of nodes. In such a case any block generated faster than 40 seconds can not reach half of the network

And if blocks were generated every 5 seconds, most of them will only reach a tiny part of the whole network no matter how small they are. So the whole network will generate lots of conflicting view of which subtree is the biggest subtree, thus become segregated

How can this problem be resolved?

Actually it makes the problem significantly worse as more orphans leads to more opportunities for a larger miner to have an advantage over a smaller one through orphans.

Note the equations for P(Q,L) in the paper I'm working on analyzing centralization incentives - they all depend on the block interval in such a way that a smaller block interval makes the larger hashing power more significant.

I suggest you correct your post.

This is what confuses me, if 32 transactions per KB, a 320KB block will make it 10240 transactions per block, not the 242.4 transactions per second that stated on that paper page 21

But since they are using a different method to propagate the blocks, maybe what they said is true? Unfortunately that 242.4 TPS is given by a formula which is unclear for its meaning, I have to read more

You need to multiply blocksize b as well.

I will read the full paper more carefully, just a glance from the paper:

"Practically, individual nodes’ limited bandwidth imposes an additional constraint on these parameters. If every node’s bandwidth is at least 0.427 MB per second, then the network is able to maintain a rate of 1 blocks per second and b = 320 KB per block, with 10000
transaction hashes per block, achieving a TPS of more than 214.0"

If drop this value from 1 block per second to 1 block per 30 second, then TPS will drop to 7, the same as current design

Yep most hardware in use for mining has second to multisecond latencies, not even getting into the latencies of global propagation in a network of decentralized volunteers (rather than trivially coerced corporate interests).

But I think if you fixate on one second you're not getting the value of of the paper. Just multiply their numbers by 10 if you find 1 second is a bit outrageous considering the practicalities that their analysis excluded.

This assumes no locality to the transactions. If transactions aggregate (by geography for example or by business type) then people will often find blockchains in common near the leaves without needing to go to the root (less often than the 25% of the time you indicate one hopes.)

Very interesting. Reminds me of banks and clearing transactions between banks within a country vs. transactions that require a transfer between banks in different countries.

great lets take something extremely complex and misunderstood, and right when people start to understand it and believe in it, lets change it. Yea thats where i want to keep my money. Sarcasim aside how will this effect the distribution of bitcoins?

From a miner's perspective, I don't see how 1 block per second is possible: It takes at least 1-2 second to re-initialize the miner and get new work from the network, if new blocks arrive every second, it means the miner would never get ready for the real calculation to take place 

That's a totally sound and valid reason to worry.

I guess, if that were the main concern after the paper is assessed to be desirable, the idea of forking the Bitcoin network as it stands with its current volume, looks like a much better option than an altogether new alt-coin. We could instantly be testing on high transaction volume.

A hard fork will most possibly be rejected by miners, unless they have enough motivation and reached a consensus

I read the paper, it seems not very clear to me, hope there are several real examples without using formulas, it is easy to miss some special situation if only using generalized formulas

It's a valid concern. I don't think anybody wants to sacrifice long-term security for quicker transactions. If it gets past its initial stage of acceptance it will be heavily debated. Worst case scenario we could just fork the chain, which isn't bad in my opinion.

How can this modification be used to exploit Bitcoin?  Could this change become a vector for shenanigans later?

When you can't beat it, start influencing technology selection and whoila, eventually you get your backdoors...

paranoia or food for thought?

Nah, if you have a chain that's dedicated to a single channel then transactions in that chain only get checked by half as many people.  Besides, it's better for people transacting within a single channel to "load balance" by picking the blockchain in their channel that has the smallest number of tx in the memory pool.

And transactions that are served by one of the two-channel blockchains never need to be in blockchain zero; that's just for tx that span 3 channels or more.  Which, in practice, is almost none of 'em.

Edit: you seem to be talking about a different approach: a "tree" of subchannels, each node of the tree having its own blockchain.  I considered that, but in that scheme it's really hard for two people (or more) who want to make a transaction to find a blockchain that they have in common where the transaction can be made.  You have to have both of them going up the tree to the lowest tree node that they have in common, which would concentrate fully a quarter of the traffic on the root blockchain, split another quarter between its two subchains, split an eighth of the traffic between their four second-level subnchains, etc.  That won't scale past about four times what Bitcoin can handle now, because the root blockchain of the tree scheme would become a bottleneck.