Gold collapsing. Bitcoin UP.
- Thread starter cypherdoc
- Start date
go1111111
Active Member
If rubles were only given to dollar holders in exact proportion to their dollar holdings, then a ruble airdrop wouldn't actually have any bad monetary effects. A random airdrop of rubles over the US is not analogous to a fork because it doesn't preserve everyone's % ownership.
The point is that after a fork one side of the fork may take marketshare from the other but it won't matter because everyone has the same proportion of coins on both forks.
Does Zangelbert ever publicly disagree with anything CSW says? The last few times I've looked in on his writings he seems to basically be CSW's PR department, which seems like the opposite of being more interested in ideas than in people.
Last edited:
Christoph Bergmann
Active Member
I have some note about the whole CSW debate.
I searched for his papers on ssrn and picked on I thought I know something about to test the hypothesis that he produces nothing but technobubble. Since I recently read a paper about quantum computer attacks on Bitcoin and wrote about it, I picked CSW's paper about quantum computers and Bitcoin. When he wrote that Bitcoin was perfectly save, my initial thought was something like "Hehe, he thinks because an address is a double hash of the public key, everything's save, and he doesn't know about the double-spending attack I recently read about." It turned out he know'd about it, but delivered the essential information the scientists whose paper I read did not deliver: How long do Quantum Computers need to break ECDSA? According to CSW even 1mio qbits need 1week to break it. As a double spending needs you to break it in seconds, CSW is completely right that Qantum Computing will almost never be a problem - while the scientists whose paper I made a source for my article have dramatized the problem to push their idea of a solution.
I don't know if this says anything about the selfish mining attack, because I don't understand the details, but if we make a battle between csw and the scientists, CSW clearly won when it comes to Quantum Computing and Bitcoin.
Sources:
https://poseidon01.ssrn.com/delivery.php?ID=894066006095123112065099087122107092118059041019064065110101090089025125007096065121110039062059057028033082027091001123099114108038036022041026099121104020114006087042026042081119017113006070089102117084024090010118029093010007114123069014097021004111&EXT=pdf
I searched for his papers on ssrn and picked on I thought I know something about to test the hypothesis that he produces nothing but technobubble. Since I recently read a paper about quantum computer attacks on Bitcoin and wrote about it, I picked CSW's paper about quantum computers and Bitcoin. When he wrote that Bitcoin was perfectly save, my initial thought was something like "Hehe, he thinks because an address is a double hash of the public key, everything's save, and he doesn't know about the double-spending attack I recently read about." It turned out he know'd about it, but delivered the essential information the scientists whose paper I read did not deliver: How long do Quantum Computers need to break ECDSA? According to CSW even 1mio qbits need 1week to break it. As a double spending needs you to break it in seconds, CSW is completely right that Qantum Computing will almost never be a problem - while the scientists whose paper I made a source for my article have dramatized the problem to push their idea of a solution.
I don't know if this says anything about the selfish mining attack, because I don't understand the details, but if we make a battle between csw and the scientists, CSW clearly won when it comes to Quantum Computing and Bitcoin.
Sources:
https://poseidon01.ssrn.com/delivery.php?ID=894066006095123112065099087122107092118059041019064065110101090089025125007096065121110039062059057028033082027091001123099114108038036022041026099121104020114006087042026042081119017113006070089102117084024090010118029093010007114123069014097021004111&EXT=pdf
- Aug 22, 2015
- 1,558
- 4,693
@go1111111
Let's expand...
ABC's success did not come out of a vacuum, it came out of a relationship which BU had steadily forged with a number of major miners over a year and a half. BU sent separate developer delegations to China (Nov 2016 & March 2017) who met with many miners and businesses there. It is difficult because of language and cultural barriers, but we found like-minded people who shared the original Satoshi vision of p2p currency for the world enabled with onchain scaling. A collaborate effort evolved which briefly achieved over 50% of the hashing power on BTC. Sadly the poisoning of the Western ecosystem by the r/bitcoin/bitcoin.org/bitcointalk and crypto-news media capture prevented a widespread switch to large block capable non-mining full-nodes. So, our node count languished as had XT and Classic before.
@Peter R's BUIP055 which proposed a spinoff fork was passed by the BU membership. And this was tirelessly spec'd out by @freetrader. The New York Agreement pulled the rug from BU's effort to gain hashing power for larger blocks on Bitcoin, and we were left with planning a large block client compatible with Jeff Garzik's BTC1 or putting BUIP055 into effect and forking.
Some BU members used those pre-existing miner-developer links in mid-2017 to fast-track a fork of Bitcoin because, with the NYA, time was running out to create a version of Bitcoin without the complexity of Segwit being embedded forever, once SW outputs hit the blockchain.
Kudos to @deadalnix and @freetrader who were the architects ABC's success and created a organisation which quickly attracted other capable developers. This is permissionless innovation in action.
Yes, BU should have pivoted faster on the question of Emergent Consensus. The reason we focused on that is because it is architecturally correct, removing the block limit from the protocol layer. The miners long made it clear that they wanted the 1MB resolved permanently, and didn't want the same battle at 2MB or 4MB, every time capacity became restricted. We recognized that any flexible cap, such as BIP100 was fine, as early as BUIP002. This made sense for BTC when it was obvious that hard-forks would be rare. BCH is different in that the philosophy of regular HFs allows for many protocol block limit upgrades, so a simple limit of 8MB was fine to start.
BU did not fail, it sharded and succeeded in a way which few people expected, including many BU members, creating the environment for a viable fork. Even at the recent SV conference, I had a reminder why such a long time building the relationship ground-work was so important, when I met the Hong Kong miner who mined the very first BCH blocks, at full difficulty until the EDA kicked in. He was familiar because our delegation had met him in 2016 and already established our shared views on scaling.
It's easy to look back and criticise Xthin for having exploitable weaknesses, yet, it was the Xthin initiative in early 2016 which was essential to starting the good faith relationship with miners. Xthin testing focused on the propagation delays caused by the Great Firewall of China. Compressing blocks from 1MB to 20KB was an extremely welcome development for the miners. Core had dragged its feet in this area for years, showing no enthusiasm for thin-blocks (while bemoaning how the network couldn't remain decentralized with blocks larger than 1MB). Once BU went live with this, it was very well received by the community. Core was galvanized to create its own version: Compact Blocks. I think that Xthin is superior in its use of targeted bloom filters, yet CB was superior in being hardened against attack integral to its design. Ultimately, in an adverse environment of black-hat attacks, being hardened is more valuable than block propagation efficiency.
Without @Peter Tschipper's Xthin there would have not been the relationship between BTC miners and developers independent of Core Dev, which had enough critical mass to support the fork initiative which created BCH. Without Xthin, all big-blockers would have been pinning their hopes on Segwit2X only to see it clusterfork to oblivion 2 blocks too early. Big-blockers would have been left choosing between sticking with Core's BTC and waiting for the 2nd-layer coming of LN, or divesting to alts such as ETH, Dash or whatever, and joining Mike Hearn in calling Bitcoin a failed experiment.
History is different. We have BItcoin Cash, and while we may debate relatively small matters of functionality (compared to on-chain vs off-chain scaling), we can still say proudly that Bitcoin is not a failed experiment!
Wow. I am learning a lesson on how a soundbite can compress history out of recognition.
Let's expand...
ABC's success did not come out of a vacuum, it came out of a relationship which BU had steadily forged with a number of major miners over a year and a half. BU sent separate developer delegations to China (Nov 2016 & March 2017) who met with many miners and businesses there. It is difficult because of language and cultural barriers, but we found like-minded people who shared the original Satoshi vision of p2p currency for the world enabled with onchain scaling. A collaborate effort evolved which briefly achieved over 50% of the hashing power on BTC. Sadly the poisoning of the Western ecosystem by the r/bitcoin/bitcoin.org/bitcointalk and crypto-news media capture prevented a widespread switch to large block capable non-mining full-nodes. So, our node count languished as had XT and Classic before.
@Peter R's BUIP055 which proposed a spinoff fork was passed by the BU membership. And this was tirelessly spec'd out by @freetrader. The New York Agreement pulled the rug from BU's effort to gain hashing power for larger blocks on Bitcoin, and we were left with planning a large block client compatible with Jeff Garzik's BTC1 or putting BUIP055 into effect and forking.
Some BU members used those pre-existing miner-developer links in mid-2017 to fast-track a fork of Bitcoin because, with the NYA, time was running out to create a version of Bitcoin without the complexity of Segwit being embedded forever, once SW outputs hit the blockchain.
Kudos to @deadalnix and @freetrader who were the architects ABC's success and created a organisation which quickly attracted other capable developers. This is permissionless innovation in action.
Yes, BU should have pivoted faster on the question of Emergent Consensus. The reason we focused on that is because it is architecturally correct, removing the block limit from the protocol layer. The miners long made it clear that they wanted the 1MB resolved permanently, and didn't want the same battle at 2MB or 4MB, every time capacity became restricted. We recognized that any flexible cap, such as BIP100 was fine, as early as BUIP002. This made sense for BTC when it was obvious that hard-forks would be rare. BCH is different in that the philosophy of regular HFs allows for many protocol block limit upgrades, so a simple limit of 8MB was fine to start.
BU did not fail, it sharded and succeeded in a way which few people expected, including many BU members, creating the environment for a viable fork. Even at the recent SV conference, I had a reminder why such a long time building the relationship ground-work was so important, when I met the Hong Kong miner who mined the very first BCH blocks, at full difficulty until the EDA kicked in. He was familiar because our delegation had met him in 2016 and already established our shared views on scaling.
It's easy to look back and criticise Xthin for having exploitable weaknesses, yet, it was the Xthin initiative in early 2016 which was essential to starting the good faith relationship with miners. Xthin testing focused on the propagation delays caused by the Great Firewall of China. Compressing blocks from 1MB to 20KB was an extremely welcome development for the miners. Core had dragged its feet in this area for years, showing no enthusiasm for thin-blocks (while bemoaning how the network couldn't remain decentralized with blocks larger than 1MB). Once BU went live with this, it was very well received by the community. Core was galvanized to create its own version: Compact Blocks. I think that Xthin is superior in its use of targeted bloom filters, yet CB was superior in being hardened against attack integral to its design. Ultimately, in an adverse environment of black-hat attacks, being hardened is more valuable than block propagation efficiency.
Without @Peter Tschipper's Xthin there would have not been the relationship between BTC miners and developers independent of Core Dev, which had enough critical mass to support the fork initiative which created BCH. Without Xthin, all big-blockers would have been pinning their hopes on Segwit2X only to see it clusterfork to oblivion 2 blocks too early. Big-blockers would have been left choosing between sticking with Core's BTC and waiting for the 2nd-layer coming of LN, or divesting to alts such as ETH, Dash or whatever, and joining Mike Hearn in calling Bitcoin a failed experiment.
History is different. We have BItcoin Cash, and while we may debate relatively small matters of functionality (compared to on-chain vs off-chain scaling), we can still say proudly that Bitcoin is not a failed experiment!
Last edited:
What If They ICO? Investors Seek Veto Power Over Future Token Sales
https://www.coindesk.com/ico-investors-seek-veto-power-future-token-sales/
https://www.coindesk.com/ico-investors-seek-veto-power-future-token-sales/
Does silver extend the gold supply? What about copper?
The aggregate value held in money is what what every individual wants to hold, it differs between age groups and the individual degree of long term thinking, but aggregated, it is somewhat constant. What we see on the crypto "capitalization" lists could be extended with all money types, if so the dollar would come out on top.
About constant: It is not necessarily constant, my baseline of thinking is that if we have a money type that is just as good as gold for long time, and just as good as fiat for liquidity, people on aggregate might want to hold more value in money, and less in real resources like houses.
for anyone who hasn't listened to Roger debate Samson b/c of all the other distractions out there today, you should listen now, even just for the entertainment value. not enough attention is being given to all the blatant technical and economic errors/lies in Samson's claims. he's ridiculous. what a lost soul:
79b79aa8
Well-Known Member
- Sep 22, 2015
- 1,031
- 3,440
that's the type of guy adam back hires. he's the lost soul.
just sit back and watch; no need to panic:
[doublepost=1522892809,1522892005][/doublepost]it's time to get down:
https://www.bitcoinabc.org/may15hardfork
[doublepost=1522892809,1522892005][/doublepost]it's time to get down:
https://www.bitcoinabc.org/may15hardfork
The scaling debate saw multiple clients who tried and failed.
XT was DDOSed and censored while no other discussion channels were yet available or well established.
Classic was taken out with the HK agreement.
BU was attacked and taken out with the NY agreement.
But each of the above had more momentum at its high then the one before.
ABC learned from all the above and could again build momentum on top of its predecessors.
I think ABC made a great decision to not ask for permission and to not try to achieve the majority hash rate first but like @solex wrote the support grow over time and didn't just start when Bitcoin Cash was announced at TFOB at Arnhem.
Last edited:
Zarathustra
Well-Known Member
- Aug 28, 2015
- 1,439
- 3,797
Christoph Bergmann
Active Member
It's highly misleading to say "ABC succeeded where Unlimited failed" because the goals are different.
Like XT, Classic and SegWit2x Unlimited tried to UPGRADE BTC with a hardfork. The goal was to take the whole network effect (merchants, transactions, market cap, wallets) and build a big blocks bitcoin with it. After it became clear that BU and S2X would not upgrade Bitcoin but create a new coin and lose network effects, they canceled the forks because THIS WAS NOT THE PURPOSE.
ABC however started with the purporse of creating a new coin and let BTC with all the network effects be property of Core. You could say ABC was more of a surrender than a victory, as it kills any big block movement in BTC, while starting a new coin with a new name, a new ticker, and 1/10 of transaction and market cap. While I have hope, I am highly opposed to call this the victory we strived for with Bitcoin Unlimited.
Like XT, Classic and SegWit2x Unlimited tried to UPGRADE BTC with a hardfork. The goal was to take the whole network effect (merchants, transactions, market cap, wallets) and build a big blocks bitcoin with it. After it became clear that BU and S2X would not upgrade Bitcoin but create a new coin and lose network effects, they canceled the forks because THIS WAS NOT THE PURPOSE.
ABC however started with the purporse of creating a new coin and let BTC with all the network effects be property of Core. You could say ABC was more of a surrender than a victory, as it kills any big block movement in BTC, while starting a new coin with a new name, a new ticker, and 1/10 of transaction and market cap. While I have hope, I am highly opposed to call this the victory we strived for with Bitcoin Unlimited.
Its not something that I like to do, but since this is under discussion I feel that I need to clarify one final point about the history. BU has always been 100% for the fork, and as others have mentioned we initiated it.
But BU did not create the initial client. So how did we lose the momentum?
In the weekly BU meeting on the "release_admin" channel of the BU slack I delegated freetrader to handle the BU BUIP055 "bitcoin cash" release and but he instead worked on ABC without informing me. This of course stopped our progress dead until I realized what was going on.
But BU did not create the initial client. So how did we lose the momentum?
In the weekly BU meeting on the "release_admin" channel of the BU slack I delegated freetrader to handle the BU BUIP055 "bitcoin cash" release and but he instead worked on ABC without informing me. This of course stopped our progress dead until I realized what was going on.
- Dec 16, 2015
- 2,806
- 6,088
@Christoph Bergmann - BU's emergent consensus was designed to fork only with majority hashrate, so the statement is not entirely correct w.r.t. BU - it was not canceled, it just didn't get the hashrate it was aiming for to upgrade the block size, so eventually it decided to give the minority fork approach a chance (in a separate client release).
One of the drawbacks of BU's original majority fork approach appears to be the rather unpredictable forking process that would result. If the miners have to decide whether it is safe to enact the new rules (produce a bigger block), it becomes very uncertain if, when and how this will take place. Miners don't like this uncertainty and the rest of the ecosystem does not either.
Flag day upgrades like the one we've had on Bitcoin Cash (13 Nov 2017) are better. People like certainty, and firm deadlines help with motivation.
The good thing about Bitcoin is an upgrade date is not like a wedding day. There is very little that can stop a well prepared upgrade.
---
@theZerg, I'll be happy to tell people the fuller history if you want to open that can and make inaccurate claims about it. You're clearly OK with divulging information from private BU slack channels.
Last edited:
@freetrader When you accept responsibility for the management of an important release in a slack channel containing all the BU devs and others there should be no expectation of privacy.
I have never made a big deal of this because I support ABC and multiple clients. However, if people are going to gaslight past history into a narrative where Bitcoin Cash is somehow an ABC initiative and BU "failed" then the details need to be known.
I have never made a big deal of this because I support ABC and multiple clients. However, if people are going to gaslight past history into a narrative where Bitcoin Cash is somehow an ABC initiative and BU "failed" then the details need to be known.
- Dec 16, 2015
- 2,806
- 6,088
@theZerg Then you can release the full meeting minutes from that meeting?
They will show conclusively that I only accepted responsibility for creating a branch for BUIP55 development in my personal development repository in order to accept PRs from BU devs, have these PRs reviewed by BU members and feed them back to BU's repository.
I was not put in charge of releasing BUIP55, that is a process which occurs from BU's main repo, and over which you retained control.
I don't know who is trying to "gaslight past history into a narrative where Bitcoin Cash is somehow an ABC initiative". I've tried to portray things objectively in public comments, but now somehow I'm being made the scapegoat for BU not having a client out earlier?
They will show conclusively that I only accepted responsibility for creating a branch for BUIP55 development in my personal development repository in order to accept PRs from BU devs, have these PRs reviewed by BU members and feed them back to BU's repository.
I was not put in charge of releasing BUIP55, that is a process which occurs from BU's main repo, and over which you retained control.
I don't know who is trying to "gaslight past history into a narrative where Bitcoin Cash is somehow an ABC initiative". I've tried to portray things objectively in public comments, but now somehow I'm being made the scapegoat for BU not having a client out earlier?
- Dec 16, 2015
- 2,806
- 6,088
@theZerg : Do you realize when BU devs would have needed to start preparing a minority fork client if you wanted to get it ready before UAHF (Cash) came up and ABC got the first client ready?
I simply don't understand why you give credibility to silly assertions that "BU failed". Instead of ignoring them, you validate them by seeking reasons for BU not achieving milestones that it had not set for itself. Sorry to say it, but that's wacky reasoning.
If BU had set its mind to a minority fork earlier on, it would have been ready in terms of a client.
If I'm going to take the blame for somehow "stopping progress dead" then I'm going to have to first accept that BU failed.
I simply don't understand why you give credibility to silly assertions that "BU failed". Instead of ignoring them, you validate them by seeking reasons for BU not achieving milestones that it had not set for itself. Sorry to say it, but that's wacky reasoning.
If BU had set its mind to a minority fork earlier on, it would have been ready in terms of a client.
If I'm going to take the blame for somehow "stopping progress dead" then I'm going to have to first accept that BU failed.
- Aug 22, 2015
- 1,558
- 4,693
Actually, @albin you hit on a point that I would welcome being cleared up, which is "How do the nonces being unique per miner per block affect the "memoryless" aspect?" It is not as if the hashes are created with random nonces which may be duplicates. Within the 2^256 search-space, this distinction is negligible, but does it have an effect when considering the lower bound created by the hash target?
