Gold collapsing. Bitcoin UP.

[freetrader]

This is a 100% clear confirmation that @freetrader has no idea about where the donations to ABC are going. He tries to divert the question with a desperate move, but everyone can see that he is naked.

Says on the webpage the donations to ABC will go to ABC.

Donate to Bitcoin ABC by sending BCH to the address below

Too difficult for you? Don't worry - number go up!

Now heading towards the 110 BCH marker...

 

[kyuupichan]

[doublepost=1559688322][/doublepost]

no that's probably not fair. @jtoomim is also genuinely concerned with scaling, but he approaches the issue from the perspective of a small miner. whereas i am afraid bitcoin maximalism and protecting the business interests of small miners are incompatible.

can't resist noting (because nobody else did here) that collected fees on that > 1.2 GB block on testnet were greater than the block subsidy, for the first time in bitcoin.

Indeed he doesn't want to invest; he wants to collect the rent and sit on his ass.

I have to correct you about the fees being greater than the subsidy. That happened for at least one BTC block, and I think a handful, at the peak of the fee "market" back in Dec 2017 / Jan 2018; over 25 BTC total. Or maybe you didn't count that as Bitcoin, lol.

 

[Norway]

What really happened back when @Thomas Bakketun and I published our IBS (Incremental Block Synchronization) paper?

It's a funny little story, and I will tell it now.

If you don't know it yet, IBS basically removes block propagation time between connected nodes. It doesn't replace block relay and the time related to that. (Note to self: A similar tier 2/block relay service could be made for connecting to newbie miners that are not well connected and BSP's (Blockchain Service Provders). The incentives are there for all parties.)

Thomas and I sort of discovered this idea together. After talking about it for a few minutes, we agreed to drop what we had in our hands (the KaChing protocol and implementation) and worked on IBS exclusively for 3 days. Big whiteboards are your friend.

After publishing it, we got some feedback. The two most remarkable feedbacks were these: (Paraphrasing from memory, Slack and Twitter are horrible as historic sources.)

Peter Rizun @Peter R: This is a very interesting form of pre-consensus!

Craig Wright: This is not BitCoin. It's pre-consensus!

Me: It's not fucking pre-consensus!

I got so mad at CSW, I tweeted "Bye bye, troll" and blocked him on Twitter!

Time passed, and last week @Thomas Bakketun and I went to the Toronto conference. On developer's day (wednesday last week), we hear that the Bitcoin SV node is going to implement a refined version of IBS! We were giggling like little girls and nodding to eachother during the presentation!

As far as I know, @shadders & co discovered the same solution as we did to smoothify the whole process and remove the network and CPU spikes independently of our paper. Because it was an obvious solution waiting to be seen by anyone wanting to scale bitcoin.

@shadders did not implement our silly drip feed fee priority system (thank god, it's stupid when blocks are never full), but added methods to delete pre-commited transactions and change their order (simple but brilliant.)

It was very cool to see that our idea is getting used in the real world!

Finally, in case @shadders read this, I'd like to highlight the last chapter of our paper. It may or may not make economic sense to do it (@shilch demonstrated how fast this can be done with cheap GPU hardware), but it's an option:

Incremental validation
For each peer a node can decide if it will just store the incoming candidate block transaction set or do incremental validation. Incremental validation allows for extremely fast block propagation. When an end of block message is received, all that is left to do is to validate the provided block header and coinbase transaction and compute a few missing nodes in the merkle tree. There is no need to make a final decision on this. Each node operator can continuously assess what is the best policy. It’s also possible to use a different policy for each peer.

EDIT: The last chapter explained: Build merkle trees for only the largest miners if there are many miners and the process is costly.

 

[Norway]

Says on the webpage the donations to ABC will go to ABC.

 

[Norway]

I got so mad at CSW, I tweeted "Bye bye, troll" and blocked him on Twitter!

It's all good now. No hard feelings.

Left: @Thomas Bakketun Middle: Satoshi Nakamoto Right: Me

Behind the photographer: Girls grinding and twerking like there's no tomorrow!

 

[jtoomim]

no that's probably not fair. @jtoomim is also genuinely concerned with scaling, but he approaches the issue from the perspective of a small miner

No, I do not. I approach the issue from the perspective of a developer.

As a medium-sized industrial miner, I can always do what all other miners of my size do: I can join a large pool. I spend $47,000 per month on electricity, and I get quite a bit more than that in revenue. I'm not a "small" miner at all. But that's completely irrelevant to the argument I've made.

The argument is that selfish mining is a real phenomenon, and large pools can use their concentrated hashrate to get more block rewards than they deserve based on hashrate alone, and that those effects get especially strong when blocks get larger than the infrastructure and software can quickly process. In fact, selfish mining will happen *accidentally* in those circumstances. If blocks are 256 MB with current infrastructure, and if a pool with 5% of the network hashrate has bandwidth and block validation power that is 10x faster than a pool with 30% of the hashrate, the 30% pool will still earn about 4.8% more revenue per hash than the 5% pool. In this scenario, all miners will want to join the biggest pool, until that pool ends up with >51% of the network hashrate. I consider that undesirable.

But as a miner, I wouldn't be affected, because I'd be part of that >51% pool. It's only as a developer, who writes the code that determines the rules of the mining game, and as a user, who wants my transactions to be uncensorable, that I think that this system is unsafe and undesirable.
[doublepost=1559700383][/doublepost]

It was Chris Pacia. @jtoomim was the guy that claimed 1MB of data could not cross the great firewall of China in less that 17.4 seconds.

This is also not true. I merely noted that in 2016, the BU developers measured the *average* transfer time across the GFW at 17.4 sec for a 0.95 MB block. That's the average speed, not the maximum possible. They would cross faster than that sometimes, and they would cross slower than that sometimes. I've also noted repeatedly that this issue can be completely solved by switching to UDP with forward error correction, but it is not easy to solve by spending more money on servers since the issue is congestion in the China Unicom and China Telecom international traffic exchanges. For a more complete description of the underlying problem, I suggest reading this post:


That said, I know that you don't care about these kinds of details, and are going to continue to misquote me every chance you get, because you're more interested in feeling righteous than you are in the technical truth. Whatever, so be it.

 

[Windowly]

I have to agree with Jimmy here.


I am rather shocked there is no company of Nchain or Coingeek or Squire calibre working on BCH development. I would have thought with all the rhetoric there would be.

 

[Norway]

This is also not true. I merely noted that in 2016, the BU developers measured the *average* transfer time across the GFW at 17.4 sec for a 0.95 MB block.

No. You're a liar. I'm not going to dig up the links. 1 idiot can ask more questions than 10 wise men can answer.

We are not waiting for you, @jtoomim. And more important: We are not asking for your permission. Technocrats like you don't have a future in bitcoin. Bye bye, Jonathan! Good luck with your investments!
[doublepost=1559702676,1559701546][/doublepost]

I've also noted repeatedly that this issue can be completely solved by switching to UDP with forward error correction, but it is not easy to solve by spending more money on servers since the issue is congestion in the China Unicom and China Telecom international traffic exchanges. For a more complete description of the underlying problem, I suggest reading this post:

Ah, I can't help it. I'll take the bait.

Let's make this simple. The total data traffic crossing the GFC is huge and fast. But a single consumer connection may be limited.

What happens when a professional miner use multiple consumer connections to send and receive data?

 

[jtoomim]

> What happens when a professional miner use multiple consumer connections to send and receive data?

Yes, that's exactly what Blocktorrent is designed to do.

Here's the reason why this task is tricky to do right. In Bitcoin, you need to be careful that your peers can't DoS you. If they send you invalid data, you need to be able to identify who sent you the invalid data and disconnect them.

If you download different parts of a block from different peers, and if one of them changes a single transaction from the full block, then you'll only notice when you finish downloading the block and find out that the merkle root doesn't match the header. So what do you do? You'd like to ban the peer who tricked you that way and re-download the chunk in question, but the problem is that you have no idea who it was that sent you the invalid chunk. So you have to re-download the whole thing. And the next time you download it, you might get a different error, or you might get the same error. This can go on and on, especially if there's a sybil attack in progress at the same time. (Which there would be if it's profitable, and in this case it would be profitable.)

The traditional solution to this problem was to get the complete block from a single source. If multiple sources are used, then they are downloaded as full (but compressed) blocks in parallel in the hope that one peer might be faster than the others, with each download after the first just adding redundancy.

The solution I proposed in 2015 was to include in each chunk of data enough information on the internal nodes of the merkle tree so that the merkle root can be calculated. This makes each chunk independently verifiable, and allows errors in transmission or malfeasance to be detected from a single packet and isolated. This allows for work to be split across multiple connections effectively, with the work on each connection contributing to a shared goal, without losing accountability for each peer.

If you think that your professional miners are competent enough to implement this algorithm without bugs, more power to them. Point them to this post:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011176.html

I'd be happy to answer any questions they have.
[doublepost=1559705230][/doublepost]> But a single consumer connection may be limited.

That's why I recommended not using connections. UDP is not connection based, it's packet based. If 5% of your packets get lost, then you send 110% of the packets you'd minimally need to transmit the block, and ensure that the extra 10% contain redundancy data that can be used to reconstruct the 5% that are missing. It's a much better solution than your multiplexing idea, as it completely skips the extra round trips needed for retransmits, and eliminates the TCP congestion control problem entirely.

 

[Zarathustra]

Says on the webpage the donations to ABC will go to ABC.



Too difficult for you? Don't worry - number go up!

Now heading towards the 110 BCH marker...

2.86 BCH to 'BU'; 28.81 BCH to 'BU's enemy, the shitlord.

 

[rocks]

Now this is the GCBU up thread that I remember from years ago, nothing but moon charts for pages.

 

[freetrader]

2.86 BCH to 'BU'; 28.81 BCH to 'BU's enemy, the shitlord.

Zarathustra's personal contribution to BU / BCH: 0
[doublepost=1559720577][/doublepost]@Norway

Craig Wright: This is not BitCoin. It's pre-consensus!

LOL, "BitCoin".

But this is one of the rare moments when I half agree with CSW.
Your scheme was pre-consensus.
Deal with it

I got so mad at CSW, I tweeted "Bye bye, troll" and blocked him on Twitter!

Maybe a sensible reaction.

[...]On developer's day (wednesday last week), we hear that the Bitcoin SV node is going to implement a refined version of IBS!

Congratulations, you have been played like a chump.

As far as I know, @shadders & co discovered the same solution as we did

You have to adopt this rationalization to remain in the cult.
I mean, it's not like they're reading this thread and ready to take your idea.
SFYL!

"BSV - no protocol changes - except preconsensus!"

 

[torusJKL]

We will never know if nChain was inspired by IBS, came up with it independently or copied most of it.

What we do know is that it was published here first and was never implemented by BU.

 

[BldSwtTrs]

I think this will be the year when failing to research the CSW story on your own will stop being just a matter of missing out on insights into Bitcoin and instead start being a matter of missing out in general. For too long, being wrong about Bitcoin failed to be expensive. Those days are coming back.

What do you think about Paul Le Roux's appearance in the Satoshi case?
https://www.investinblockchain.com/new-evidence-suggests-satoshi-nakamoto-is-paul-solotshi-the-creator-of-encryption-software-e4m-and-truecrypt/amp/

What if Le Roux was the real mastermind, CSW was his partner, and CSW wait for Le Roux to be in jail to steal its BTC and the recognition?

That would explain all the fake proofs and forging from CSW.
I have 0 doubt that CSW was involved since day 1 in Bitcoin and that he is a superior mind, but I cannot makes sense of all the forging and fake proofs.

The Le Roux hypothesis would allow to connect all the dots.

 

[cypherdoc]

I doubt he had anything to do with inventing bitcoin. I remember learning about how to use Trucrypt back in the early days as it was one of the favored ways to secure the Satoshi wallet. the two softwares were completely different in that the wallet had no security features built in, not even password protection. I remember it's two authors were anonymous and it was on the verge of being commercialized as Veracrypt as the authors had made an announcement they were no longer going to maintain it. you'd think if Leroux had written the Satoshi code and wallet, it would have had at least some similar security features; at least private key protections, like AES, which was eventually added by core. or maybe hidden volumes. and, as is often stated, Bitcoin doesn't strictly rely on "encryption" per se.
[doublepost=1559741159][/doublepost]it's also not like prisoners don't hear outside news. he could easily make a public statement calling out CSW as a fraud.

 

[lunar]

That would explain all the fake proofs and forging from CSW.
I cannot makes sense of all the forging and fake proofs.

The big assumption you and many others are making here, is that these 'forged' documents have any provenance. Isn't it also possible, that materials have been stolen from CSW, then doctored to make them look incriminating and smear reputation?

Check this latest post out

The whole sector is clearly going to battle, in a litigation, hunger games. The year of the Purge, will be remembered as very sad and messy phase of rebirth, in Bitcoins lifecycle. The truth needs to come out, and it appears that's whats going to happen.

I personally doubt Craig would make comments like these, without some solid evidence?

 

[cypherdoc]

a good example of a forged doc trying to make CSW look like a fraud was that short list of about 6 addresses, witnessed by his lawyer on Craig's phone, that was doctored to display large balance BTC that had nothing to do with him.

 

[freetrader]

Now heading towards the 120 BCH marker...

Plus I heard the Chinese community at BitKan have collected 60+ additional BCH.

Assuming those funds are separate and will be combined later, that brings the fundraiser to ~21% in just a matter of days, with 56 days to go.

So much for "the development cannot be crowd-funded".
[doublepost=1559749260][/doublepost]For my price-attached friends...

 

[rocks]

@freetrader, let's assume ABC achieves its fundraising goal of 800 BCH after much promotion.

How many magnitudes of order more resources does BSV and nchain have? It is a serious question.

The fact ABC is even promoting its fundraising goal and positioning it as a success to me is an admission of failure....

 

[satoshis_sockpuppet]

@rocks
How many magnitudes of order more resources does the US (or almost any) government have over BSV?


Or maybe it's one and the same resources? Hm!