Gold collapsing. Bitcoin UP.

[trinoxol]

https://bitcoinassociation.net/bitcoin-sv-node-version-0-2-1-optional-release-makes-mining-faster-more-profitable/

The blocksize limit will be removed in February 2020. By then we will probably see sustained 2GB blocks on mainnet with serious transaction counts. 1.5 years of work was all it took to achieve this.
[doublepost=1563018721][/doublepost]> They need to be able to enforce this...

Would you personally be comfortable owning 1 million $ in Bitcoin if possession was illegal? What would you do with that money when you are ready to spend it? What would you buy and how?

Assume a punishment for money laundering of up to 5 years in prison.

 

[cypherdoc]

gold was made illegal to possess in 1933 via FDR. estimates were maybe only 50% was turned in. that hodling made people alot of money when possession was made legal again as the gvt apparatchiks had sold its haul for a mere ~$35/oz, iirc.
[doublepost=1563029999,1563029388][/doublepost]no one country is going to ban Bitcoin out of fear of being left behind. can you imagine anyone banning the internet in the 80's? it's been 10.5 yrs of fight and struggle and Bitcoin is still here, alive and well. the proverbial cat is out of the bag. furthermore, even if a cabal of western countries was able to get together and say yin, Iran, S Korea, Russia, and or maybe China would say yang. in fact, Iran has already said yang.

 

[trinoxol]

During that ban you couldn't use gold. It's (black) market value was very low. It had lost 99% of its value through the ban. People got lucky that the government eventually lost its grip.

> no one country is going to ban Bitcoin out of fear of being left behind.

That is true. I have a strong sense that we are past the point where (at least western) governments can ban Bitcoin.

 

[cypherdoc]

>During that ban you couldn't use gold.

that's what I meant by hodling. it paid off. and yes, the cat is out of the bag. the question is, which of the three Sha256 coins will win. and yes, I do think there will be a winner. which also is the reason for all the trolling between coin supporters.
[doublepost=1563031724][/doublepost]don't forget; one of the earliest theories is that the NSA created Bitcoin on behalf of the USG.

 

[cypherdoc]

excellent. I like the part about training miners as to their new responsibilities in block formation:

https://bitcoinsv.io/2019/07/13/quasar-upgrade-24th-july-recommendations-roadmap-to-genesis-part-2/
[doublepost=1563057081,1563056300][/doublepost]mind you, all the game theory outlined in this update was worked out for BU back in 2015. in fact, @shadders example is a bit restrictive as there's another possibility:

>2/ If the miner that mined the larger block has minority hashrate then the block will get orphaned and your Bitcoin SV instance will reorg back to the majority chain.

Its very likely that miners won't have a complete picture of every other miners hard cap. a minority hash miner of 49% could release a 1G block knowing or suspecting that at least one other minority hash miner of at least 2% network share also has their hard limit set at 1GB thus allowing the block to be accepted and built upon.
[doublepost=1563057801][/doublepost]furthermore, given the above example, I (I think it was me) coined the "creep" theory while designing BU. this is where it's likely miners won't jump their hard caps all the way to 1GB from 512MB all at once. they're more likely, once a few 512MB blocks have successfully made it across the network and the mempool has approached 512MB worth of tx data, to take their hard (and soft) caps to maybe 550MB in a slow creep upwards in blocksizes produced and accepted, testing the network while trying to avoid orphans. all other miners are incentivized to take this same approach as this risk potentially gains them greater tx fees the more they can process. there is historical evidence that this will be their approach as seen from the relatively smooth blocksizes produced increase seen between 2009 and when we hit the 1mb limit.

 

[79b79aa8]

>all the game theory outlined in this update was worked out for BU back in 2015

then BU went from being unlimited to being limited to an organic end user growth model that may or may not be sound. but there is no point in whining anymore. as ever, informed observers have been given ample time to vote with their coins.

 

[freetrader]

https://github.com/KarolTrzeszczkowski/Mecenas-recurring-payment-EC-plugin

Seeing useful contracts being implemented on Bitcoin Cash warms my heart.
Excellent work by Karol Trzeszczkowski.

A note for this forum: it's made possible by CDS and P2SH

 

[solex]

furthermore, given the above example, I (I think it was me) coined the "creep" theory while designing BU. this is where it's likely miners won't jump their hard caps all the way to 1GB from 512MB all at once. they're more likely, once a few 512MB blocks have successfully made it across the network and the mempool has approached 512MB worth of tx data, to take their hard (and soft) caps to maybe 550MB in a slow creep upwards in blocksizes produced and accepted, testing the network while trying to avoid orphans. all other miners are incentivized to take this same approach as this risk potentially gains them greater tx fees the more they can process. there is historical evidence that this will be their approach as seen from the relatively smooth blocksizes produced increase seen between 2009 and when we hit the 1mb limit.

Exactly right @cypherdoc This description is how the largest mined block would slowly advance in size under the emergent consensus model which BU implemented in its software in 2015. I doubt many orphans would occur as the creeping up of the largest block size mined would be a highly visible statistic. Miners adjust their maximum accept size in advance. It is a logical response to total fees growing along with transaction counts.

>all the game theory outlined in this update was worked out for BU back in 2015 then BU went from being unlimited to being limited to an organic end user growth model that may or may not be sound. but there is no point in whining anymore. as ever, informed observers have been given ample time to vote with their coins.

I keep having to repeat that the maximum block limit in BU is 2.1GB. There is a default limit setting which is pitched above organic demand, as the miners have long made it clear that they welcome guidance on defaults in software, like most users do. That guidance can be ignored, as we see in BTC where the Core default of 750KB is ignored by all the miners. So, BSV is following suit with a much higher limit. Very good.

To be clear, BU has not changed its model. If BCH blocks remain smaller than 32MB in a future scenario where the BCH mempool clogs up BTC-style causing excessive fees, loss of usage, crippling network effect, then the miners have a solution: use the BU client to mine larger blocks.

 

[cypherdoc]

I miss you man

 

[trinoxol]

> A note for this forum: it's made possible by CDS and P2SH

I like CDS very much. It enables on-chain enforced smart contracts. It is worth reiterating that BSV does not have on-chain enforced smart contracts. Once you spend a transaction you can send the money anywhere you like and exit the "smart contract". All BSV smart contracts rely on the involved parties cooperating.

A smart contract must be able to encumber the spending of the outputs with spending conditions. BSV can't do that. A TxOut script cannot verify what TxOut scripts the spending transaction uses.

 

[trinoxol]

The EVM seems to be designed very badly. Also, look at the diff of the fix (https://github.com/0xProject/0x-monorepo/commit/ff70c5ecfe28eff14e1a372c5e493b8f5363e1d0). They had to make nasty hacks to deal with this.

This seems like a very bad choice to me as well:


Ethereum 2.0 wants to run their smart contracts in web assembly (EWASM). WASM was made for browsers. It has a very large attack surface. Browsers have trouble keeping it secure. It is reckless to use this for a billion dollar public blockchain. One security bug and all Ethereum nodes experience remote code execution at the same time.

Ethereum is squandering their lead just like BTC is.

 

[Norway]

I like CDS very much. It enables on-chain enforced smart contracts. It is worth reiterating that BSV does not have on-chain enforced smart contracts.

CDS does not represent a fundamental difference in script capabilities.

I invented a way to avoid OP_CHECKDATASIG. One of my partners in Bitcoin.no, Thomas Bakketun, figured out the details. No need for OP_CHECKDATASIG.

https://www.yours.org/content/betting-using-bitcoin-cash-smart-contracts-f4367d93a6dd

 

[trinoxol]

This seems to be a way to do betting when an oracle provides an outcome. This scheme works inside of a single transaction.

If you want to make an on-chain chess game where two adversaries can only play valid moves and the winner takes the money BSV can't do it. BCH can, BTC can't.

 

[freetrader]

I'd like to see some rebuttals to Jonathan's analysis of the BSV large block construction.

They've been mostly using an unreliable trick to avoid the performance problems associated with large blocks. The specific feature that causes large blocks to propagate slowly is not actually the size of the block in MB, but the number of transactions in the block, so what BSV has been doing is making batches of non-financial transactions that are unusually large (about 10 kB each), so they can generate 128 MB blocks that only have 1,398 transactions. These huge blocks propagate very quickly, instead of the 250,000 transactions that a natural 128 MB block would have, and that allows BSV to advertise "128 MB blocks!" based on their best-case scenario without actually having done the engineering to survive the worst-case scenarios.

Because the blocksize limit is in place specifically to protect BCH against those worst-case scenarios, BCH decided not to follow BSV with this strategy, and has retained the 32 MB limit until we have handled the worst-case scenarios properly.

 

[trinoxol]

It is true that BSV had large blocks with fairly few transactions. But they are scaling the number of transactions per second, too. They are obviously aware of this and they stated they are working on it.


5000 TPS. The number might be a bit unrepresentative of real-world conditions but we are moving in the right direction. (Actually, 500k/10min is 1000 TPS. Not sure why this website shows 5000 TPS).

The blocksize is important for network propagation and BSV is making great progress there. The number of transactions is limited by the structure of the node software. The network is not an impediment to raising this number.

Whatever critique you find with the BSV strategy, it is just a temporary thing. Fundamentally, nothing can prevent the eventual success of very large blocks with very large numbers of transactions.

BCH also seems to not understand that miners are incentivized to produce blocks that actually propagate. The protocol does not need to enforce limits. Orphans are fine. See https://bitcoinsv.io/2019/07/13/quasar-upgrade-24th-july-recommendations-roadmap-to-genesis-part-2/

 

[shadders]

1/ he's and idiot
2/ he's a self confessed failed small miner
3/ our advertised limit isn't 128mb its 1.4gb
4/ we've done 400k+ txs per block on testnet and same order of magnitude on mainnet so he's full of shit with his 1300 txs in block bollocks
5/ our capacity continues to grow because we are actually working it
6/ we can because someone actually cares enough to fund it
7/ he's an idiot

 

[Norway]

I hope the BCH developer community, BU included, listens to @jtoomim and keeps the default max blocksize at 32 MB until he gives the green light.

 

[cypherdoc]

"we will not allow it until..."

 

[trinoxol]

Just like BTC, BCH has its own set of dogmatic beliefs about why scaling doesn't work. It's just the same.

When BCH and BSV split I did not fully understand why. It totally makes sense now. BSV is an entirely different league and it's fundamentally incompatible with the way BCH wants to go about things.

There is no middle ground. No compromise is possible. BTC and BCH must be refuted and go away.

 

[jtoomim]

@trinoxol, I would love to be wrong about this. I wish EC were the solution we needed. But each time I calculate the incentives, I find that they're perverse. If you can explain to me how my math is wrong, I would very much appreciate it.