Proofread of theZerg's paper "An Examination of Single Transaction Blocks..."

[Zangelbert Bingledack]

See @theZerg's very cool paper at http://www.bitcoinunlimited.info/1txn (Note: pdf link broken)

So far I have only proofread the Abstract, Section 1, and the Notes.

Typos:

• Abstract: [see below]

• Section 1: "may include any transactions that are not in any ancestor blocks"
• Section 1: "and switch their ASICs to mine that candidate."

• Note 1: The third sentence does not end: "assumption that [is beyond the scope of this paper? cannot be rendered objectively? etc,]."
  
• Note 2: Missing a period.
• Note 3: "this section of the paper focuses on"
• Suggested rewrite of Note 6: "[6] From the perspective of a third miner, it is irrelevant when the two sibling block solutions were found. To maximize profitability all that is relevant is when the miner can begin mining full-transaction blocks. Therefore the miner should stop verifying a large block and start verifying a small block if the work needed to verify the small block is smaller than the work left to complete the large block." (Also was missing a space at the beginning of the Note.)
• Suggested rewrite of Note 7: "[7] This analysis makes the game-theoretic assumption that mining pools are rational and attempt to maximize their profitability. One caveat is of course that mining pools would need to be aware of this analysis and implement this behavior."

Style points:

• "single transaction blocks" --> "single-transaction blocks" is less ambiguous when possible
• "Bitcoin Network" --> "Bitcoin network" seems more usual, and sometimes the lowercase version was used, too; usage should probably be consistent throughout the paper
• ".1" --> "0.1" seems more standard
• "2" --> "two"; "3rd" --> "third"; etc. (numbers below ten are usually written out, except when abbreviating or when the number itself will be used in a mathematical context, hence "1-txn" seems good but "1-transaction" doesn't because it's not an abbreviation; prefer "one-transaction" as an adjective when not abbreviated)
• Difference between a "short" block and a "small" block? Both are used. I prefer "small" if this is to be along the same spectrum as large, and to avoid confusion with the length of a chain.

• Section 1: "available uncommitted transactions in the network" --> "uncommitted transactions available in the network"
• Section 1: "It must be propagated to the other miners." (all the bullet points should have periods, or none)
  
• Section 1: "network latency and bandwidth limit propagation speed, and validation requires intense CPU use and possible disk access."

• Note 1: "predominately" --> "predominantly" is ~10x more common according to Google

Suggested rewrite of Abstract:

Abstract. The Bitcoin network's creation of normal blocks and single (coinbase-only) transaction blocks is analyzed using multiple empirical approaches. A maximum Bitcoin network transaction commitment throughput of 60KB/sec is derived. The significant role of single-transaction blocks in limiting this throughput is then shown. The miner revenue equation in an unlimited-block environment is derived, and it is shown that the optimum strategy for mining pools is to mine competing short (small?) blocks when presented with a block that is so large that its validation time will affect fee revenue. It is shown how this strategy naturally discourages large block sizes as a function of transaction throughput, coinbase reward and average transaction fees, and how it encourages larger blocks as fees increase, but in an asymptotic manner. In fact given today's network (topology? [a little unclear what network characteristic is relevant here]), typical transaction fees of 0.1 to 0.4 BTC/MB actually discourage block growth, and the profit-maximizing block size will not exceed about 30MB regardless of fee spent [unclear whether this is intended to include fees greater than 0.4 BTC/MB].

Therefore, the choice of block size is a de-facto hash-power weighted "vote" controlling average block size and can replace proposed schemes that use explicit voting and/or flexible capacity.

 

[theZerg]

Awesome! Not at computer to make the fixes at the moment tho

 

[Peter R]

Here are my notes from the Abstract and Introduction:

Abstract: make a single paragraph.

Write “0.1” rather than “.1,” etc.

Par 1: not *in* ancestor blocks.

Par 2: several step -> five steps:

- The block must be propagated to the miner
- The miner must validate the proof-of-work and each transaction in the block
- The miner must update his mempool by removing the transactions included in the block
- The miner must create a new block candidate using this block’s hash and the remaining transactions in his mempool
- This candidate block must be submitted to the miner’s hashing infrastructure to begin the mining process.

Par 3: put brackets around "(and transactions the it is certain cannot exist)" because this seems like an side point and adds confusion otherwise.

Par 3: "only needs the hash" -> "only needs the block header" (want nonce and previous hash too)

Par 3: “Since miners maximize profit by maximizing the time their ASICs are hashing” —> not necessarily. I’d say they want to keep their equipment producing useful work if possible.

Par 3: “1 transaction block candidate” —> I would standardize and call these either “single-transaction blocks,” “1-transaction blocks,” “one-transaction blocks,” or “empty blocks.”

Par 3: “construct a block candidate containing as many transactions as available” —> not really, they won’t include TXs that pay too low a fee. You could cite my fee-market paper here.

 

[Peter R]

Notes on Section 2: Observations

Par 1: Can you be more precise than “middle of October 2014”?

Par 1: “19 November, 2015” -> “19 November 2015” (remove comma)

Par 1: “The following figure” —> “Figure 1”

Par 2: “(shown in minutes on the x axis)” —> there is no “x-axis.” Refer to this as either the horizontal axis or the abscissa.

Par 3: “[0,t)” -> “[0, t)” (also use italics for single-letter variables everywhere in the paper)

Eq. (1): I would write it as

P(t) = 1/T e ^ (-t/T)

where T is the block time target, but both are acceptable. This way I wouldn’t have to define “lambda.”

Par 5: “To eliminate data errors, it is necessary to not use the block time stamp.” —> “Another methodology exists that does not rely on the block time stamp.”

Par 5: “figure 1” —> “Figure 1”

Par 5: Also make it clear that (R) is the ratio [put it after the word “ratio” not after “number of samples”]

Before Eq. 2: The average time a 1 transaction block was mined is simply: <nothing here>

Eq. (3): T log [-1 / (R-1)] is actually equal to T log[1/(1-R)], which gets rid of a minus sign. Also, I would write “T” rather than (600) to so that the equation is correct regardless of one’s measurement units.

The approximation you make after Eq. (3) is what I referred to as the “fast-block approximation” in Section 7 of my subchains paper. You could cite if you wanted to add some precedence.

I would also explain the approximation using the power series expansion

log [1/(1-R)] = R + R^2/2 + R^3/3 + …

which is approximately equal to “R” for R << 1 (which is the case in this analysis).

Par before Figure 3: “1MB” -> “1 MB”

“1-txn blocks” —> this is different once again

“equation 3” -> “Eq. (3)”
[doublepost=1450972867,1450971722][/doublepost]3. Analysis: preamble

Par 1: I’d propose something like this instead (it would be nice to include an Appendix that shows the p-value calculations in more detail too):

“Figures 2 and 3 appear to indicate a relationship between the length of time miners generate empty blocks and the size of the preceding block. To determine whether the relationship was statistically significant, we calculated the probability that *no* relationship existed by assuming that the resulting data points were a result of randomness (the null hypothesis). The p-values for each method were 6.2 x 10^-15 and 1.9 x 10^-12, respectively, allowing us to confidently reject the null hypothesis. Indeed, there is a significant relationship between prior block size and the frequency of empty blocks.”

Par 2: “figure” -> “Figure” when you’re talking about a *particular* figure such as “Figure 2.”

Par 2: “seconds/MB” -> “s/MB” or maybe “sec/MB”

Par 2: “It cannot be determined from the data why this is the case.” What do you mean? Isn’t this just the network latency? E.g., the time to communicate some small amount of data like just the block header?

Par 3: “While data shows a clear relationship between block size and generation of 1-txn blocks.” is not a sentence.

 

[theZerg]

when do I use two vs 2? Figure 2? Equation 2? Chapter 2?

> In fact given today's network (topology? [a little unclear what network characteristic is relevant here])

No not the topology, its the coinbase rewards and validation capacity. How about "today's network metrics"

> Par 3: "only needs the hash" -> "only needs the block header" (want nonce and previous hash too)

@Peter R are you sure that you really need the header... I was wondering about this. If you look at CBlockHeader, it ONLY refers to hashPrevBlock. so I think that people might send the full header (because why not) but really you'd only need the hash.

class CBlockHeader
{
public:
int32_t nVersion;
uint256 hashPrevBlock;
uint256 hashMerkleRoot;
uint32_t nTime;
uint32_t nBits;
uint32_t nNonce;
[doublepost=1450978105][/doublepost]Par 3: “Since miners maximize profit by maximizing the time their ASICs are hashing” —> not necessarily. I’d say they want to keep their equipment producing useful work if possible.

How about "Since miners maximize profit by maximizing the time their ASICs are hashing blocks likely to be added to the chain"


> Eq. (1): I would write it as
> P(t) = 1/T e ^ (-t/T)
I used lambda because that's how the literature describes poisson processes and thought it would be good to provide something very familiar.

 

[Peter R]

"when do I use two vs 2? Figure 2? Equation 2? Chapter 2?"

Typically, if you're referring to a specific figure, table, equation, or section you would capitalize the first letter of the word and use an arabic numeral. At Ledger, we would use: Fig. 2, Table 3, Eq. (4), Section 5.

The rules for when to write out a number as a word versus when to use an Arabic numeral are somewhat subjective. Here is what we settled on for the Ledger Author Guidelines:

[doublepost=1450979678,1450978770][/doublepost]"@Peter R are you sure that you really need the header... I was wondering about this. If you look at CBlockHeader, it ONLY refers to hashPrevBlock. so I think that people might send the full header (because why not) but really you'd only need the hash."

Indeed they only need the hash; however, they cannot verify that the hash meets the difficulty target without the complete block header. So I guess strictly what you wrote is correct.

 

[theZerg]

> I would also explain the approximation using the power series expansion

I did not end up using the approximation for the calculations. So I think that continuing to explain the approximation may confuse people. Instead I emphasized that the approximation was not used. I think that its important to add it in because many people could use it to understand how the more complex math relates to the real network.

(let's see if mathml works here)

One can therefore see that this equation is approximately equal (given Bitcoin's expected block discovery of 10 minutes or &lambda; = 1/600) to the much more intuitive equation
<math>
<mrow>
<mi>S</mi>
<mo>=</mo>
<mi>600sec</mi><mo>*</mo>
<mfrac>
<mrow> <mtext>number of 1 transaction blocks</mtext></mrow>
<mtext>total samples</mtext>
</mfrac>
</mrow>
</math>
that could be used if the block discovery probability was constant. This approximation was NOT used in the following charts, it is only included here expository reasons.

 

[Peter R]

3. Analysis: Effect on Network Throughput

Par 1: “transaction bandwidth” —> “transactional bandwidth”??

Par 1: “limited in an upper bound by its ability to” —> “has an upper bound limited by its ability to”

Par 1: “But it is…” -> “It is…”

Par 1: “a independent” -> “an independent”

Par 2: Validation rate is 60 KB/s; propagation impedance is 17 s/MB.

Par 2: “1/17” -> “1 / (17 s/MB)”

Eq. (4): If “z” is the propagation impedance in time / bytes, then the equation should be:

Tu = zQ + T

and Eq. (5) should be

Th = Q / (zQ + T)

BTW—I don’t like using Tu for a something with units of time and Th for something with units of bytes per second. "Th" makes me think it’s a time variable. Maybe I'd write:

Q_c/T = Q / (zQ + T),

where Q_c is defined as the network block size capacity (i.e., the size of the block that would take the full ten-minute block time to propagate).

After Eq. (5): If z is the propagation impedance, then z = 17 sec / MB. Also, write T = 600 s so that both terms measure time in the same units.

After Fig. 3 [note also that you have two Figure 3s]: Here I would write “approximately ten minutes” rather than “10 minutes” since you’re not being precise.

Also: “32MB” -> “32 MB”

And “30KB/sec” -> “30 kB/s” (or /sec, just be consistent).

 

[Peter R]

3. Analysis: Effect on Block Discovery

Par 1: “miner/mining pool” —> “miner or mining pool”

“T4: New block created” —> “T4: New block candidate created”

“T6: A block that builds upon the T0 block is found by someone on the network” -> “The next block is found by someone on the network”

Add a space between “(T5,T6)” —> “(T5, T6)” [several places]

“chapter 2” -> “Section 2”

Remove capital “T” on “the” after “chapter 2, The”

“Poisson process equation (1).” -> “Poisson process Eq. (1).”

“Dec 6,2015 to Dec 15,2015” —> “6 December 2015 to 15 December 2015”

“We can simulate a network where miners do not generate 1-txn blocks by ignoring intervals where the second block was a 1-txn block.” —> this makes it sounds like this is simulated data.

“In the next chart, light blue bars show the block discovery likelihood if no blocks were being generated during the validation time interval (T0,T5), and yellow shows the contribution of the 1-txn blocks.” —> don’t you mean the blue bars are for filled blocks??
[doublepost=1451012053][/doublepost]3. Analysis: Effect on Block Size

I'm quitting here for the day. My initial read over this section tells me that it can be simplified (the other sections are quite straightforward and well presented but I found this a bit confusing...will look more later).

Merry Christmas!

 

[Peter R]

Here are what the Orks of Mordor are saying about @theZerg's paper:

I'm not sure I understand their critique, however. The first half of the paper proves that the frequency of empty blocks is dependent on the previous block's size. It follows from this--and from basic Poisson results--that miners must be mining empty blocks for longer when the previous block was large. So what exactly is the critique?

@theZerg proved this claim with a hypothesis test (he assumed there was no statistically significant effect and then refuted the null hypothesis [with a tiny p-value to boot]) and then performed a regression to calculate a propagation impedance of about 17 sec / MB. Interestingly, that was the same propagation impedance calculated independently by Tradeblock using an entirely different methodology.

It is fairly clear that larger blocks take longer to propagate than smaller blocks, holding all other variables constant.

 

[theZerg]

They are wrong on 2 counts.

1. As Peter R said its not an assumption, its shown with data.

2. I never claim it is propagation delay. From the empirical perspective of the paper -- I do not know what the reason is (but from a personal perspective, I'm guessing its mostly the time to validate the block). It is very unlikely to be propagation delay due to the size of blocks and the Relay Network.

I'm going to put this on Reddit tomorrow.... thanks to everyone who helped!!!

As a last chuckle, I just realized I have to thank someone named "Zangelbert Bingledack" in my acknowledgements -- did you PLAN that?? .

 

[Peter R]

@theZerg:

By propagation delay, I was referring to all of the time involved including verification. I don't care where the delay comes from, just that it exists. That is the point of the "propagation impedance": to capture how quickly the blocks spread without worrying exactly what was causing the delay (because it doesn't matter).
[doublepost=1451190155][/doublepost]Oh, and best of luck tomorrow!

 

[theZerg]

Yes, we agree. I do like your "impedance" term a lot -- "resistance" is something the people feel they know (in EE, I mean). "impedance" is this amazing and somewhat mysterious effect (AFAIK it is caused by reflection interference patterns) and the point is don't focus too much on the why's of it, just understand that it exists and consider its ramifications.

 

[Zangelbert Bingledack]

@theZerg

Way back when, I got the idea to choose the silliest name possible so that my ideas and those I support would be forced to stand on their own merits, so I guess technically that was part of my plan

(H/T: Eddie Izzard)