Please do not quote the entire gigantic OP just to write "When LN?"

Most of the network did it in Jan '16.. So would you care to explain how observable SPY mined 1-txn blocks decreased 6-fold while orphan rates decreased something like more than ten fold, following the median block propagation times as improvements rolled out in new releases?  You argued that the reduction in orphaning is because increased spy mining, if that were the case you'd expect to see more empty blocks but now we see almost no empty blocks-- less than half a percent. ... Not just why there are fewer empty blocks, but why there are vastly fewer orphans when spy mining was already ubiquitous in Jan 16, and why the number of orphans (and the delay times when they were created) decreased along with block propagation with new releases?

And today, instead, every node can propagate ahead of validation, without any special casing the first, and without any configuration. CK is obviously no idiot, and yet CK has mined invalid blocks.  Idiot proof behaviour isn't just for idiots, mistakes happen to everyone.

The chart shows the dramatic speedups in block propagation. SPY mining was ubiquitous (more than half the network hashrate using it, as observed by miners following invalid block forks) before the starting point on that graph.

Go look at the rate of empty blocks on the network, there are very few now.

In the last 10000 blocks there were 63 coinbase-only blocks.   For blocks 384000-394000 (Around January 2016, the start of that chart) there were 414. And yet there were many more orphans back then.

Block propagation is now so fast that there is little reason to implement spy mining anymore, but even so-- now miners spend much less time using  it, which is good for Bitcoin security.  I wouldn't be shocked if spy mining now causes miners to lose money and not only from following invalid chains: the loss of transaction fees for spy mined blocks can cost more than the amount saved from a small decrease in orphaning risk.

Although there have been a number of invalid blocks mined in the last couple years, there has been no evidence of other miners following these invalid block forks as they did in the past due to SPY mining.

It turns out that we can get essentially the same performance without you having to add "trusted nodes" which have the security and maintenance problems of SPY mining, and we did. But it was not at all "obvious". Now every node gets the benefit of relaying ahead of validation all the time, without risk to the network, and without problematic configuration.

Again you are confused. Matt's public relay network is centralized (because, duh, it's matt's network). FIBRE is just a P2P protocol, you are confusing the two. Other parties run the FIBRE protocol, most just don't invite you to connect to them (better for DOS resistance).  Another one that many people do connect to is the blockstream satellite broadcast, however.  If you recall how we got on this tangent above: I suggested it would be nice to integrate it so more nodes could use it without the trouble of running a patched version, and you disagreed.


It does that but that isn't where the performance comes from, its simply a necessary component. FIBRE performance comes from not needing to get any reply to reconstruct a block in all cases, even if there are unknown transactions, while only needing to receive as much data as was unknown, without the sender having any idea what data was unknown... and even doing this if there is packet loss (1-3% is typical on long international links).   So if you are missing a couple packets worth of data from anywhere in the block, FIBER will recover the block after you've received a couple packets-- even if many of the packets that were sent got lost along the way. Your knowledge of already relayed transactions is fully exploited, but if a few are missing they don't cause a significant slowdown or require a round-trip. It needs to use UDP so TCP doesn't undermine this property, but if all it did was use UDP it would still need roundtrips, the magic is in the stuff that makes it never need roundtrips.

The graph is from Till Neudecker's excellent observational paper on block propagation in Bitcoin: https://dsn.tm.kit.edu/bitcoin/forks/  The 10 second number you are mentioning is the time that it took for blocks to be accepted and advertised by 50% of the reachable nodes in the network.   That line is interesting, but it's not the part of the graph I was referring to:  What I was referring to was the all the coloured X marks, which are the creations of orphans.

(The median time line does however strongly indicate that the reduction in orphans is due to improved propagation, rather than e.g. miners further centralizing)

The reduction in orphans is very much pool related.


Many of the things needed to achieve block propagation speeds that we've achieved are not just unobvious to expert engineers, they're so unobvious that it takes considerable time to explain them.  Not all of the things, but many of them.  Even the ones that are obvious to you have subtle implications: For example, forwarding a block before verifying it is an obvious improvement to someone with a bit of background, but doing it without creating a massive DOS vector with nodes willing to forward around garbage data, requires some subtle considerations.

Indeed, by design. BIP152 is basically optimized for the (hopefully) low latency hop between you and a FIBRE speaker. For low delay links, e.g. <10ms FIBRE doesn't have a huge advantage over BIP152, because when the link is short there is usually almost no packet loss and multiple round trips are cheap.  But it would be better if standard node software could speak the FIBRE protocol too since the network can't consist of only <10ms links, it just hasn't been worth the engineering resources and attack surface trade-offs yet... (or at least hasn't been the lowest hanging fruit, esp since there is the option to run FIBRE externally)

Thanks for making my point that you totally don't understand what's going on there. FIBRE is a protocol for getting blocks around the world with essentially the lowest delay possible all the time even if it has unknown transactions, even across high latency links, and even if the links lose packets. There isn't anything centralized about FIBRE. FIBRE is an alternative to BIP152 which uses all the more complicated techniques that get really low propagation delay that we left out of BIP152.  Matt has a public network of nodes that use FIBRE themselves, some miners run their own FIBRE-using nodes. Matt's public network is a centralized thing, which has its own advantages (e.g. DOS mitigation, getting almost everyone connected without a bunch of additional hops in the way), but those advantages are largely independent of and in addition to the FIBRE protocol advantages.

Not in a way that aversely impacts mining: See figure 16 in the paper. Most of the change in tx propagation behaviour is for the first hop because the first hop is always performed via reconciliation instead of flooding.  So this change ends up with nodes (including miners) receiving the transactions with a similar amount of simultaneity.

Erlay itself doesn't slow down propagation, but it benefits from different trade-offs in batching than plain flooding does-- so for our figures in the paper we chose batching intervals that gave a better bandwidth usage trade-off. But in any case, what matters for propagation is tx simultaneity and not total delay. But it's a great question that you ask, and we should cover the simultaneity impact more directly, as it's another consideration in choosing one parameter set over another.

Also, FWIW, even if that weren't the case, the existing mining process delays essentially hide tx propagation now; which is why txn are requested very infrequently except for unpropagated txn ( 2.7% of blocks, currently, on my node at home; mostly from miners that include zero fee payout txn).  Unpropagated transactions are also not an issue for FIBRE, and there is also a on-hold PR for Bitcoin Core that makes mining more intelligent about including low fee potentially not well propagated txn, but at the moment its on hold because it largely seemed unnecessary.  BIP152 also has the prefilled transactions mechanism which is unused except for coinbase transactions, though its a pretty weak mechenism compared to FIBRE.

I think it would be really cool to get FIBRE into Bitcoin Core, but Matt isn't interested at this time, and it would likely take a pretty extensive rewrite to make a simplified and cut down version suitable for inclusion.

Actually, what you're describing there does essentially nothing against the issue Erlay addresses: relay overhead. But for what resetting your IP actually achieves-- making your node unavailable for new nodes to sync off you-- you'd be much better off setting an upload limit (-maxuploadtarget), decreasing your peer count (-maxconnections) or just disabling inbound connections entirely (-nolisten). Not only would those work better for you (and not require changing your IP, which not everyone can do) but they'd waste less time for other nodes by not leaving them uselessly attempting connections to your old IP.

Sorry, that is just entirely untrue. Matt did a tremendous amount of implementation work, improvement, measurement, deployment experience, etc... contributions which cannot be overstated but the designs of both compact blocks and fibre were both created by myself, as were many of the fundamental research behind them. Many other people helped as well (e.g. Pieter)-- Matt did not do that work alone.

They were neither known nor at all obvious, and still today even with them widely deployed people still struggle to understand how they work because of how mind-blowing they are (particularly FIBRE, which people consistently misunderstand even after its carefully explained to them because they don't believe that what it does is actually possible, so they continually misunderstand it).  The vague handwave "Make block propagation faster" is obvious, but doing so in a way that works under diverse loads doesn't create attack vectors or bad incentives and which actually works is something else entirely.

Kano, you haven't explained your thinking so I cannot respond except in generalities.

Why do you believe it hurts miners?

By making it possible for the network in general to use higher connection counts while wasting less total bandwidth on relay overheads it should make the network (and individual miners) much more robust against attack, and potentially enjoy even lower orphan rates. As a result I expect it to be helpful to miners.

Would people who "hated miners" work so diligently to knock orphan rates down to almost nothing?


The article you linked is a bit confused, Alex Leishman's tweets are more informative: https://twitter.com/Leishman/status/1133404078413713408

You've been suckered.

Bitcoin is not turing complete.  If some small additions were made (e.g. enabling covenants) it would be, all wright did is repeat long known and publicly printed stuff and jumble it up with technobabble to confuse the reader and pretend that (1) he was showing turing completeness (he wasn't) and (2) that he was saying something new or unknown.

It is also not particularly desirable or even useful for a thing like bitcoin to be made turing complete.  Bitcoin isn't a computer (if it were it would be the stupidest computer ever conceived) but a _validator_.  Turing completeness isn't required to validate any claim.

I would really like to know how wright managed to fool you on this.  He repeated over and over again that he had cellular automata running on bitcoin proving its turing completeness, but then never pointed to where they were (and, of course, people looked and there were none).  So is that all it takes? just repeat something a number of times and then wait a year and wham, a few percent of people will just believe?

FWIW, I just removed a nearly year old post with a .bitcoin directory download that would have stolen all your bitcoins.

Case in point as to why these "download the blockchain" links are a disaster. God knows how many people got robbed due to it.

Unless you have a very fast connection downloading the blockchain and importing it will take longer than just letting it process as normal, because if you download in advance you cannot process and download at the same time.  This has been true since version 0.10 or so.

A criminal offence with a maximum $2500 fine.  $2500 + $55 vs how many millions from the BSV pump/dump?  Seems to me that Wright had a great ROI on his latest fraud.  ... even better if the US government never bothers prosecuting, AFAICT they never have before.

Maybe not at the same time because there are other things like per-connection memory usage that need to be optimized too... but eventually, sure. Probably you'll see per connection memory usage get improved, then the default inbound connection limit get increased, and only after that's well deployed would the default outbound level get increased.

I don't agree that they're clear for handling airdrops/spinoffs.  The simplest interpretations result in absurd consequences.

Some people have advocated that a spin-off is income at the time it came into existence at its market prices.

Following that kind of absurd interpretation to its absurd ends means that we could bankrupt Warren Buffet, for example, by creating a bitcoin spinoff that traded at $1/coin and also included an output paying 100 trillion coins to his website's SSL cert key... causing him $100 trillion in taxable income.

Someone you have no relationship with handing you cryptocurrency you never asked for and expecting nothing in return -- potentially entirely without your knowledge or even any reasonable way for you to discover it-- should never create an income tax obligation.  It certainly shouldn't create an income tax obligation based on some absurd highly illiquid scamcoin market last trade price.

I do agree that its clear otherwise, although _significantly_ inconvenient for general usage. Fixing that will likely take an act of congress: IRS is unlikely to wave tax obligations for small cryptocurrency transactions on their own.

Some of the things people are asking for, like being able to use like-kind exchange to cover swapping between bitcoin and ethereum seem flat out absurd to me. IRS might permit something like that but only if they can't resist showing how ignorant they are about cryptocurrency.  The model of treating Bitcoin largely like stock is a generally workable one, and you sure as heck can't do like kind exchanges between unrelated stocks!

Erlay reduces node bandwidth usage by 38%, or by 75% if connectivity is increased from 8 to 32 for attack robustness reasons.

The opposite: transaction relay is more decenteralized and robust if nodes have more connections. Erlay allows having more connections without using significantly more bandwidth.

In a follow-up to the ideas discussed in https://bitcointalk.org/index.php?topic=1377345.0

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016994.html

Craig Wright is a scammer who has published a bunch of obviously fake evidence trying to connect himself with the creation of Bitcoin but he has no connection.

I demand you transfer all your property to me. Little do you know, but your parents sold you to me while you were an infant for a magic bean. I could easily demonstrate some evidence truth of this claim, but I won't because you're not worthy of me. Instead I'll make up some easily disproved fake evidence: Your parents have blue hair and signed using the blood of ghandi, since he is your godfather.  No one will hold these obvious lies against me, because they're simply there to protect me from having to pay taxes on this highly profitable trade I made all these years ago... Now I will include some genealogical and legal terms to prove my expertise (imagine these being screamed): lineage, naturalization, pedigree, hypothecate, fideicommissum, demurrer.

Oh wait, you're suddenly so confident that my absurd story is bullshit and you refuse to go along with it?

Funny that.

No. It cost $55 to file a claim (false or not).  It's technically a crime to make a false claim but the maximum penality is $2500 and as far as anyone has determined so far, no one has ever been charged under it.


Unfortunately this isn't true. If wright tries to take any action he would simply lose because he is an enormous scammer, but it would be his move so he simply won't do it.

Only the government can enforce the law against making a false registration, but presumably they won't because they haven't bothered before.

Fortunately, the copyright registration has absolutely no effect other than just helping wright defraud people.  -- just like it had no effect when someone previously did it (if you search you'll see there is another one for bitcoin done by a prior scammer back in 2016). https://bitcointalk.org/index.php?topic=4519202.0

This thread is really about Ethereum which deservedly gets the vast majority of David Gerard's sneer.

David Gerard makes a name for himself being contrary.  He's often right about the things he criticizes, but like anyone else who makes their opposition part of their identity he can often be wrong too.

There is a _ton_ of outright fraud in this space, especially around Ethereum.

If you're feeling exposed by him, perhaps you should reconsider your actions (and "investments")?

[Kinda funny that these newbie account vaguely threatening posts start up right when the target starts ripping into Wrights latest false claims...]

Bitcoin is strong enough to take a bit of mud thrown its way and come out the better for it-- various premined scamtokens? ... not so much.

Repeated dishonesty from Samourai have barred them from ever receiving a payout from the bounty as far as I am concerned: I will not be signing a transaction paying them. Evaluating the privacy of systems is difficult even when the involved parties are honest and easy to work with, it is far too difficult when they are actively misleading.  Personally, I would urge my friends to not use that wallet.

As far as other stuff, there has been efforts in progress to do some awarding for a couple months now. It takes time to evaluate things and work with the recipients.  If it didn't this bounty would have been gone years ago when "darkwallet" demanded the whole thing then mobbed us with unreasonable demands (including public campaigning which was vigorous to the point of harassment) to pay it all to them when the result didn't provide the advertised privacy and didn't even stay available due to the operating model.