Gold collapsing. Bitcoin UP.

[cypherdoc]

someone's pumping the SV mempools again. at some point this should get interesting:

https://bchsvexplorer.com/
[doublepost=1542648645][/doublepost]and of course, our always wonderfully jammed BTC mempool:

 

[AdrianX]

The miners will step in to secure Bitcoin Cash against attacks by using PoW as it it's planned in Bitcoin's design (see the whitepaper).

FTFY

Obviously, the White paper does not account for a persistent minority chain.

I'm just confused (in the absence of the social narrative) as to who the miners are, are the miners the ones mining the chain, or are the miners some investors who are not invested in successes of the network, the ones who sell hashpower to the attacker who steps in the change the rules?

 

[cypherdoc]

i think the major distinction we're looking at is that there's only one set of BCH dedicated miners; Coingeek, SVPool, BMG pool. they're willing to go all out from the beginning of their existence and even now, losing money while doing so, to support the original Satoshi Vision.

 

[lunar]

So how long before Roger and Jihan run out of money?

What's the chances Bitmians IPO falls through after this?

Good read here if you think economics governs the system.

https://medium.com/@thebchboys/bitcoin-hashwars-day-5-classical-mechanics-and-chain-splits-35ea5cdaff3b

Splitting coins right now is reckless.

 

[cypherdoc]

splitting coins works. it's just whether trading them is reckless.
[doublepost=1542651401,1542650538][/doublepost]

So how long before Roger and Jihan run out of money?

What's the chances Bitmians IPO falls through after this?

Good read here if you think economics governs the system.

https://medium.com/@thebchboys/bitcoin-hashwars-day-5-classical-mechanics-and-chain-splits-35ea5cdaff3b

Splitting coins right now is reckless.

that's a good read. couple things:

1. it's a big assumption that CSW holds significantly more BTC than Bitmain. that may be so, but it certainly isn't a given.
2. the physics analysis totally ignored that if Bitmain did indeed liquidate much/most of it's BTC, that retained value could exist in the form of a huge USD warchest. i didn't look at their financials to know if this is true or not.

 

[cypherdoc]

everybody suffering:

 

[Peter R]

@Zangelbert Bingledack

Although there's no block explorer for me to calculate precisely, it seems the highest sustained throughput (60 min average) was about 25 MB x 6 = 150 MB on the BSV chain.

Interestingly, CSW is now saying that the 128 MB blocks are "coming soon" instead, as though the plan was never to produce 128 MB blocks on the November 17th Stress Test.

That said, it would no longer surprise me if they are able to generate a series of 128 MB blocks. I was playing close attention during the stress test: the SV nodes running the public software bogged down and ran slow. The SV miners were certainly not running the code that's in the Github repository.

@jtoomim noticed that SV pool would post new work for the next block approximately 2 minutes before the nodes running normal SV would connect the latest block to the chain tip. It would thus appear that SV, Coingeek and friends were connected with some sort of fast relay network, or were using a pre-consensus algorithm to improve block propagation between each other.

It's not a bad thing in itself to connect to other miners with a fast relay network, but with a 2 minute head start, a new SV miner who was not part of their private relay network would be at a strong disadvantage. The orphan rate for the miners with the 2-minute lag would be approximately e^(2/10) - 1 = 22%, while the miners with access to the private relay network would be close to 0.

This was not correct. Better analysis suggests the fast-relay hypothesis is false.

On further analysis, it looks like the "fast relay hypothesis" for SV was wrong. There were at least 7 orphans during the Nov. 17th - 18th stress tests.

Looks like ~5% orphan rate when the average block size is ~5 MB. This suggests 32 MB blocks are taking ~192 seconds to propagate between SV miners.

 

[Christoph Bergmann]

@Peter R

Do you know what was the size of the orphaned blocks? Would it help miners to build smaller blocks to prevent orphans?

 

[79b79aa8]

Obviously, the White paper does not account for a persistent minority chain.

I'm just confused (in the absence of the social narrative) as to who the miners are, are the miners the ones mining the chain, or are the miners some investors who are not invested in successes of the network, the ones who sell hashpower to the attacker who steps in the change the rules?

yes, those who are equally vested in the success of AI chips, sha256d and other miners, and a portfolio of cryptocurrencies and cryptotokens, toward a favorable market valuation.

 

[freetrader]

@Peter R

Do you know what was the size of the orphaned blocks? Would it help miners to build smaller blocks to prevent orphans?

I cannot independently confirm and don't particularly trust BitMEX Research, but take it as one datapoint relating to your question.

 

[lunar]

it's a big assumption that CSW holds significantly more BTC than Bitmain. that may be so, but it certainly isn't a given.

This is a slow motion, high stakes game of poker. Both side are clearly holding a good hand. Question is, who has a royal flush?

I see very few people on the SV side advocating coin splitting. It's clear to me where most of the maximalists went, and also which side is playing the infinite game.

i think this could be a very expensive lesson, for those playing politics, like the exchanges.

I mean Kraken, wtf.

"Custodial losses taken on due to attacks originating from nChain or its affiliates will be socialized among all BSV holders on Kraken. Given the volatile state of the network and threats that have been made, Kraken cannot guarantee perfect custody of BSV."

That's not how Bitcoin works.

 

[Christoph Bergmann]

I cannot independently confirm and don't particularly trust BitMEX Research, but take it as one datapoint relating to your question.

Yes, I know the tweet. But since 16-17mb are not that much for SV currently, I'd love to know if these blocks have been orphaned because they have been extraordinarily large, or if they have been orphaned because the other pool mined even bigger blocks (for some reason, selfish mining?).

I'm not that much a fan of "big big blocks", but of "letting the network find a block size without developers setting a limit". That's why I was in love with BU's approach since day one. I take orphans as "the real blocksize limit", and I welcome them to incentivize miners to keep blocksize in a sane scope, so that HD / IBD requirements for nodes don't get prohibitive. And that's why I'm sceptical of the CTOR goal to decrease orphan rate of much much bigger blocks.

But I only know this in rough theory, so I'd be highly interested how it works in real live. I think what's going on at SV is currently the best experiment for this we ever had.

Really curious about your opinion, @Peter R and @Peter Tschipper, who architected ParVal, the perfect concept to faciliate the blocksize regulation by orphans.

 

[Norway]

Are you aware of any miners that used / is using BU to mine according to SV rules? At best of my knowledge there's none, this is why I took the liberty to use BU rather than "BU clients not following the SV rules".

I have no way to know for sure what clients the different miners use, but it's not unreasonable to assume that there are only the SV clients on the SV chain. I (over?)reacted to the words ABC/BU chains because I have seen multiple people claiming BU is against SV. But I don't want to nitpick the language, it was reasonable in your context.

Note that @Peter R has claimed that BU is not neutral on twitter:

This extra 4 EH should shift the playing field in favor of ABC/BU.

According to what Bred said here ("[t]he stress test team have spent the weekend working through numerous technical issues [...] We are pleased to announce an impending demonstration of big blocks on the Bitcoin SV chain. BABC next.") seems like the "missing" stress test was due to "numerous technical problems" rather than "ABC is just blacklisting the Shotgun txs" as @Zangelbert Bingledack said on Nov 17th.

What is strange is that in a previous tweet Brendan said the problem was "due to transaction propagation issues on the BABC chain".

Not sure why I'm mixed into that discussion.

 

[AdrianX]

Looks like ~5% orphan rate when the average block size is ~5 MB. This suggests 32 MB blocks are taking ~192 seconds to propagate between SV miners.

@Peter R, SV is a fork of ABC, and ABC does not have Graphene or Xthin. Do you know if SV is using compact blocks or are they relaying the old fashioned way?
[doublepost=1542665049][/doublepost]

I mean Kraken, wtf.

"Custodial losses taken on due to attacks originating from nChain or its affiliates will be socialized among all BSV holders on Kraken. Given the volatile state of the network and threats that have been made, Kraken cannot guarantee perfect custody of BSV."

That's not how Bitcoin works.

The risk is depositing BSV selling it then reorging the chain is high. I think given BSV does not meet their listing requirements I agree with their statement. BSV being mined at a subsidized cost would be susceptible to reorgs if the miners stopped supporting it.

Given there are no Deposits and withdrawals there is 0 impact of a reorg and socialized losses at this time.

 

[Norway]

38 MB block.
https://www.bitfire.io/blocks/557333

 

[Peter R]

Yes, I know the tweet. But since 16-17mb are not that much for SV currently, I'd love to know if these blocks have been orphaned because they have been extraordinarily large, or if they have been orphaned because the other pool mined even bigger blocks (for some reason, selfish mining?).

I'm not that much a fan of "big big blocks", but of "letting the network find a block size without developers setting a limit". That's why I was in love with BU's approach since day one. I take orphans as "the real blocksize limit", and I welcome them to incentivize miners to keep blocksize in a sane scope, so that HD / IBD requirements for nodes don't get prohibitive. And that's why I'm sceptical of the CTOR goal to decrease orphan rate of much much bigger blocks.

But I only know this in rough theory, so I'd be highly interested how it works in real live. I think what's going on at SV is currently the best experiment for this we ever had.

Really curious about your opinion, @Peter R and @Peter Tschipper, who architected ParVal, the perfect concept to faciliate the blocksize regulation by orphans.

Here are the details on 5 of the 12 orphaned blocks I've found so far:

The orphan rate is high because:

(a) the blocks are big

(b) mempools are unsynchronized due to the high transaction throughput, making things like Xthin and Compact blocks fail.

@Christoph Bergmann: Yes this is empirical confirmation of my orphaning theory (although I don't think many people disagree with it any longer anyways).

 

[cypherdoc]

impressive:


@Norway beat me to it
[doublepost=1542671796,1542670980][/doublepost]

But I only know this in rough theory, so I'd be highly interested how it works in real live. I think what's going on at SV is currently the best experiment for this we ever had.

this can't be emphasized enough. heretofore thought impossible accomplishments are pushing the voluntaryists and the multicoining miners into uncomfortable positions to "explain" the findings while simultaneously scrambling to optimize the code to handle new heights. this is how financial competition will improve the ecosystem.

 

[Norway]

Almost 64MB block.
https://www.bitfire.io/blocks/557335

 

[cypherdoc]

meanwhile, has anyone noticed that CSW hasn't attacked anyone or anything? no checkpoints, no ddos, and certainly no reorgs. simply going about proving bigger blocks, and real big blocks. something no one thought possible.
[doublepost=1542672899][/doublepost]i once labelled small blockists pessimists and big blockists optimists. it's time to reassign ABC supporters as the real pessimists.

 

[freetrader]

I'm an ABC, BU and XT supporter and I am very optimistic we'll get to an open implementation that can handle 1TB blocks before nChain & co.