> If you want to ask me on importance of aesthetics now, however, I have to say that data structure aesthetics is more important to me than code.

I definitely agree on this point. I may have said something along the lines of simplifying code at a few points, but I also (and more vehemently) have said things like "remove cruft from Bitcoin's design and forge a leaner, purer, and more elegant Bitcoin Cash." By this I'm referring primarily to the protocol and the system elegance. The effects on implementation complexity are derivatives of the simplification of the data structures themselves.

> And there a continuous partial order along the chain has greater appeal to me.

We disagree on this. As the transactions naturally form a DAG and not a sequence, I think that enforcing a linear sequential data structure is arbitrary and inelegant. I think it is more elegant to describe the chain as a sequence of sets, with no arbitrary data included beyond what is inherent in the DAG and the block-level timestamp.

>> With Graphene, encoding the order of the remaining 5% of transactions takes as much data as encoding the unordered set of all 100%...

> Can you explain this? I don't see how now

Encoding order for small-ish blocks isn't too hard. It scales O(n log n) with the number of out-of-order transactions (the offset values become larger and take more varint bytes), but that's not too bad in non-adversarial cases. The reason that the order information is a big deal is because

**IBLTs**, the core part of Graphene,

**are ***ridiculously efficient*. The size of a Graphene encoding is not linear with block size or transaction count. It's only dependent on the difference in transactions found in mempool (or a feerate-truncated version thereof) versus in the block. Typical blocks with 40,000 transactions can be encoded in around 2 kB with Graphene, or about

**0.4 bits** **per transaction**. On the other hand, encoding order information for a 40k tx block with 2k of out-of-order transactions will take around 3 kB for a near-optimal-efficiency encoding (which may take quadratic time to compute and will use int lengths that aren't a multiple of 8 bits) and around 8 kB for a

more typical (linear time) encoding. So yeah, the order information for 5% of a block isn't huge in absolute terms, but it will more than

**double to quintuple the total message size** in typical scenarios and do a lot worse in adversarial ones.

Source for Graphene stats:

This article, as well as personal communications and public lectures at Scaling Bitcoin Dec 2015 with Rusty Russel back when he was working on IBLTs. It's possible that I'm a bit off on the 2 kB typical number. I'm not an expert on Graphene. I'm more certain about the order numbers, as I've worked on code to describe residual order information for partially sorted blocks.

[doublepost=1534203105,1534202236][/doublepost]> As far as I can tell, this "attack" can be done by simply waiting a little before you send the block, and is orthogonal to transaction ordering.

No, delaying the transmission of a block is a bit different, as it's harder to selectively slow propagation to certain individuals that way. You can delay the block's arrival at your enemies' servers by at most one hop's delay that way. If your block has a well-known or easy-to-determine compact encoding, then that one hop duration will be short.

By changing around the order, you can create a scenario where you (plus co-conspirators) know a simple encoding (based on a secret weak block), but for which there is no publicly known simple encoding. This means that you can transmit your block quickly to wherever you want it to go, but the block will travel slowly everywhere else. If you're the 2nd largest miner and you want to use the hashrate of the 1st miner without their active participation and collusion, you can set up a VPS in the same datacenter as theirs, and transmit your block quickly to that VPS with the simple encoding, but use the large encoding and high LAN bandwidth to move it the last hop.

As a selfish miner, being able to pick and choose who gets your block is the unholy grail. It allows you to punch well above your weight in terms of selfish mining efficiency. If your hashrate is 20% and you can get your block to a 30% miner with a 1 minute latency advantage over the rest of the network, that gives you and your unwilling collaborator an expected 5% orphan rate advantage over the rest of the network.

By eliminating the order information, we can eliminate an entire class of attack vectors all at once. Nearly all blocks would propagate well, and the remaining attack vectors are not as easy to profit from.The only remaining tools I can think of that an adversarial miner would have would be blocks with secret transactions (which necessarily cost a lot in the opportunity cost of lost fees, and still take a long time to validate even with unwilling collaborators), and transactions that are designed to be slow to validate (which give no benefits with unwilling collaborators).