Gold collapsing. Bitcoin UP.

[Peter R]

@cypherblock

The visualization is accurate for any size of payments over LN. It is not the "discrete" nature of satoshis that cause the liquidity problem, but rather the fact that the coins cannot leave the string they are on.

 

[cypherdoc]

@solex

b/c BU is listed on this page, does this mean it has implemented checkpoints as well?:

https://cash.coin.dance/nodes

 

[cypherblock]

The visualization is accurate for any size of payments over LN.

The visualization is accurate in representing the max that can be sent (which was indeed the question you asked), my point was, it seemed to represent a "coin" as an unsplitable thing, which is true only for satoshis (at the moment). LN clearly has its limits and one of those is : the max you can send to someone depends entirely on the route and current channel capacities in that route.

 

[rocks]

@rocks:

But for any transaction or block, I only need to learn of it once. So if I'm connected to M peers, each peer need only send me N/M of the information I need. The number of peers, M, doesn't affect the information required to be sent. No?

I don't see it that way (although I have not been following closely for a few years so node to node communication might have changed).

A full node that maintains a mempool and unconfirmed transactions, will when it receives a new transaction broadcast that transaction to the M nodes it is connected to, or some subset of them, this is an order M operation per transaction. Similarly for connected nodes it did not broadcast that transaction to, they might send the transaction to the node, this is also an order M operation.

An intelligent protocol will not actually send the transaction and instead first check if the target node has received the transaction in order to reduce bandwidth. However that check is still done and is itself an order M operation.

So IMHO for individual nodes it is still O(M*N).

That said individual nodes only connect to so many other nodes, from 8 to a few hundred, and will cap connections at that many peers. So it becomes a smaller constant times transactions for example O(100*N), which yes is O(N). But an individual node's traffic still scales with the number of peers and will increase if it needs to connect to a larger number of peers. The fact that M is usually small and so can be considered a constant in practice, does not change that it is still a scaling factor. At least that is based on my knowledge of Bitcoin circa 2016.

 

[Peter R]

@rocks

Yes, nodes send out INV messages to ask if their peer wants a new transaction or block before actually sending it.

 

[Norway]

Does anybody here know if the BU client is ready for 512 MB blocks in may? @solex?

 

[solex]

@solex

b/c BU is listed on this page, does this mean it has implemented checkpoints as well?:

https://cash.coin.dance/nodes

@cypherdoc BU has always been listed on that page. I guess you are asking because of ABC's emergency checkpointing change. I expected that would be regularised via this https://github.com/bitcoincashorg/bitcoincash.org/blob/a86ce75cbdce8b14fa90b2315ebc7f0d78e6c9cb/spec/20190515-may-upgrade.md
but it appears to be missing. So yeah, I'm not sure why there is a BCH hard-fork schedule when consensus changes can be rolled out anytime on an ad-hoc basis.

Note: the 15 November 2018 initial fork blocks for BSV and BCH have been check-pointed in the latest BU release. This is many thousands of blocks ago, so is not going to cause any consensus issues.

@Norway
BU dev formal participation in that test-net is really up to @theZerg. However, there is nothing to stop you joining it with a BU node and reporting back any issues. In fact, that would be helpful.

 

[satoshis_sockpuppet]

So yeah, I'm not sure why there is a BCH hard-fork schedule when consensus changes can be rolled out anytime on an ad-hoc basis.

Why is BU so silent about stuff like this? Is it Stockholm syndrome or something?
You guys did so much important work and have been the closest to do a hardfork on the original BTC chain .. And now BU is again being shunned.

 

[cypherdoc]

@Richy_T so this is what i was referring to. afaict, come any future upgrade, the old full nodes look to fork themselves off into irrelevancy via a new mandatory forkid:

Automatic Replay Protection

When the median time past [2] of the most recent 11 blocks (MTP-11) is less than UNIX timestamp 1573819200 (Nov 2019 upgrade) Bitcoin Cash full nodes MUST enforce the following rule:

• forkid [1] to be equal to 0.

When the median time past [1] of the most recent 11 blocks (MTP-11) is greater than or equal to UNIX timestamp 1573819200 (Nov 2019 upgrade) Bitcoin Cash full nodes implementing the May 2019 consensus rules SHOULD enforce the following change:

• Update forkid [1] to be equal to 0xFF0002. ForkIDs beginning with 0xFF will be reserved for future protocol upgrades.

This particular consensus rule MUST NOT be implemented by Bitcoin Cash wallet software. Wallets that follow the upgrade should not have to change anything.

@solex i was specifically referring to the rolling 10 block checkpoints.

 

[lunar]

@cypherblock

This is all new to me, as i'm sure it is with almost everyone else, but the neglected scripting language is far richer than most imagine.
Some fantastic pointers here. Need to read more on Forth.

https://medium.com/predict/finite-state-machines-in-script-21539501ac5e

 

[Norway]

@cypherdoc BU has always been listed on that page. I guess you are asking because of ABC's emergency checkpointing change. I expected that would be regularised via this https://github.com/bitcoincashorg/bitcoincash.org/blob/a86ce75cbdce8b14fa90b2315ebc7f0d78e6c9cb/spec/20190515-may-upgrade.md
but it appears to be missing. So yeah, I'm not sure why there is a BCH hard-fork schedule when consensus changes can be rolled out anytime on an ad-hoc basis.

Note: the 15 November 2018 initial fork blocks for BSV and BCH have been check-pointed in the latest BU release. This is many thousands of blocks ago, so is not going to cause any consensus issues.

@Norway
BU dev formal participation in that test-net is really up to @theZerg. However, there is nothing to stop you joining it with a BU node and reporting back any issues. In fact, that would be helpful.

Ok, I'll summon @theZerg :
1) Wouldn't it be a good idea to have at least 1 BU node on the Scaling Test Network (STN)?
2) Is BU ready for 512 MB blocks in may?

https://bitcoinscaling.io/

I hope politics is not crippling BU scaling efforts.

 

[Norway]

I think it will be hard for BU to be ready for 2048 MB blocks in November. But, it's possible.

I want to see @Peter R, @theZerg, @sickpig & Co kick nChain ass by scaling BU better than the 2 intercompeting SV-nodes.

But are we up for it? Or is the focus to negotiate with @deadalnix on protocol changes?

Please take a step back and see the value of a stable protocol and real demonstration of current capacity from an external business' perspective.

 

[Richy_T]

If so is it too late or would BCH and BSV be killed off?

My feeling is that BTC could still take the day. It's managed to maintain majority hash and trash like SegWit is not likely fatal. It managed to get through the 2017 bottleneck because the market softened before it could really be an issue (how much congestion was part of that Is open for debate). To me, it was/is going to be the next run-up that puts the nail in the coffin. This is why so much of what has gone on since the fork has left me exasperated.

With that said, I think it would be very hard for BTC to raise the block size at this time or any time in the near future. Most of the will to do that was shown the door.

 

[rocks]

@Richy_T but how could BTC take the day if the blocksize is never raised? To me they go hand in hand, and there is no future without more capacity (even if LN worked and was ready). Without more capacity, usage and value will have to bleed to other chains.

My view is if the cap remains then BTC is a dead end in the long run, but if the space capitulates and raises the cap then BTC will remain dominant. I'm favoring bch and bsv, but maintaining a position in BTC largely because we have no idea what will happen because it depends on individuals and thus is unpredictable.

 

[79b79aa8]

but then again, as we well know, it is not just a matter of lifting the cap. @Norway correctly points out that expanding network capacity is something that is either under development now or quickly losing competitive edge. BUIP?

 

[Norway]

I might be going out on a limb here, but I suspect @solex has the idea that...

If the current demand is X
And the capacity is 100 X
We're OK.

The problem with this idea is what Jeff Garzik called "The Fidellity Problem" in 2015.

It's also my company's problem. Our business is not going to work unless we know for sure that we can onboard a lot of people.

We can't wait for a goat beard person to approve the blockspace quota.

C'mon @Peter R! You invented these terms! Get back to science. Forget about CSW. Look at the code from nChain. Look at how they push the limits. They're on a mission!

@solex, my good man, we can't sleep at our laurels anymore. Yes, BU was the best in the world at scaling bitcoin. And we all loved it.

Frankly, it took one motherfucking year for @theZerg's parallization of the mempool acceptance code to find it's way to a public release.

This is how a funded, non-commercial organization like Bitcoin Unlimited works.

There is no greedy boss on top.

I want that greed back. The greed all BU members have.

Make my computer money worth more.

 

[Richy_T]

@Richy_T but how could BTC take the day if the blocksize is never raised?

Absolutely. Sorry if that wasn't clear but it's completely contingent on raising the block size limit.
[doublepost=1552964163][/doublepost]Is anyone else just meh about the LN stuff? It was clear it was going to be problematic back several years ago and it's just playing out exactly as predicted. The only thing that raised an eyebrow for me was the watchtower stuff. LN's failure to deliver is just mundane.

 

[cypherdoc]

We can't wait for a goat beard person to approve the blockspace quota.

this is crux of the disagreement.

on the one hand these guys say we don't need to remove (or increase) the limit now because the demand isn't there; "we'll do it when it's time" (years from now). but at the same time they warn that we need to insert all these scaling optimizations now before the protocol ossifies. so, if the protocol is going to ossify, how the heck are they going to get a blocksize increase through "years from now" ?

 

[freetrader]

And now BU is again being shunned.

From what I see BU is near half the nodes of the Bitcoin Cash network (44.13% according to cash.coin.dance today). What makes you say it's being shunned?

 

[satoshis_sockpuppet]

@freetrader
BU also almost had majority hashpower on the BTC chain..
ABC hard and softforks as they wish (without respecting the schedule) and the other implementation play catch up. Also, criticism from BU (and other) devs, for example about Avalanche, is being ignored and I think it's pretty obvious, that ABC / Amaury is now viewed and accepted (by BU and others) as the de facto dictator of BCH.

I fail to see why we need different implementations in this situation.