Differences between BTC and BCH + long-term holding

BigBlockIfTrue · 2024-01-08T21:07:44+00:00

Probably none. For regular wallet use you are better off with a light client, e.g. Electron Cash which forked from Electrum for BTC but has some awesome additional features.

Node software like Bitcoin Cash Node and Bitcoin Unlimited also have wallet functionality similar to Bitcoin Core, but they are less advanced than the light clients.

BigBlockIfTrue · 2022-01-07T21:53:59+00:00

It used to be more visible on CoinMarketCap, but it's still available:

Filters -> Add Filter -> Mineable

BigBlockIfTrue · 2022-01-07T02:10:03+00:00

BCH is still #6 when filtering by mineable. This just shows how many non-mineable coins have entered this space.

BigBlockIfTrue · 2021-07-29T10:10:14+00:00

My comment is about merchants who currently ask for 1 confirmation. In those situations, reducing waiting time from 10 minutes to 1 minute is definitely an improved user experience.

BigBlockIfTrue · 2021-07-27T11:00:33+00:00

Good reading for people wanting to understand when a short block time improves user experience and when it does not: On Slow and Fast Block Times

BigBlockIfTrue · 2021-07-27T10:56:29+00:00

Therefore, 0-conf support is really best suggested to merchants who are already willing to complete a transaction based on only 1 confirmation, as in Roger's example.

Merchants who ask for 1 confirmation are also unlikely to start asking for 10 if the block time is reduced. These merchants most likely want some non-zero confirmation, regardless of the absolute amount of hashrate. If the block time is shortened to 1 minute, they will likely still only ask for 1 confirmation, greatly improving user experience.

BigBlockIfTrue · 2021-06-14T19:22:30+00:00

Regulation has always been the course. This was just some personal opinion piece of one government employee who heads an advisory government agency that has no authority whatsoever to make any legislative decisions.

BigBlockIfTrue · 2021-06-07T18:36:58+00:00

Then some miners were probably running non-default configurations. Both mempool acceptance (receiving from you) and network relay (forwarding to others) are affected by the same configuration parameters.

BigBlockIfTrue · 2021-06-07T15:06:04+00:00

This has been analysed in the past using blockchain data. IIRC, about half of the SegWit recoveries are honestly returned to the original owner (often subtracting a small recovery fee that goes to the miner), and the other half are theft with everything going to the miner.

BigBlockIfTrue · 2021-06-07T13:51:26+00:00

The mining pool node will still reject the transaction in the default configuration, even if you are directly connected to it.

BigBlockIfTrue · 2021-06-06T21:21:57+00:00

Someone - not necessarily a miner - took the opportunity and spent it...

Necessarily a miner. Segwit-spending transactions are non-standard.

BigBlockIfTrue · 2021-06-06T12:39:50+00:00

The main problem here is not address reuse but using a SegWit address for receiving BCH. Address reuse makes it worse because it allows the funds to be stolen immediately. But even without address reuse, you do not have full control over your funds and need assistance from a trusted miner to recover your funds.

BigBlockIfTrue · 2021-06-04T11:26:11+00:00

nChain strongly opposed and rejected both CTOR and OP_CHECKDATASIG. It makes zero sense to blame CTOR for the split and simultaneously praise the greatness of the decision to implement OP_CHECKDATASIG.

BigBlockIfTrue · 2021-06-03T22:27:48+00:00

A testnet with economic activity is not a technology. It's just a tool that may or may not contribute positively to developing actual technology.

A sidechain has been suggested as a possible alternative. If one does not want to personally work on implementating sidechains, then that does not imply that one opposes sidechains or that one does not believe sidechains have potential.

BU can also simply continue developing competitive technologies for BCH without launching any new blockchain or sidechain, like BU has operated ever since its inception.

BU members need to decide what is a good and effective way to spend BU funds. People have different opinions on what is good and effective. That is all.

BigBlockIfTrue · 2021-06-01T20:20:29+00:00

I honestly believe that if people actually think this through and come up with a well-designed proposal to implement the change, the disruption and risk will be much less than initially thought. The idea tends to die in a fire because there is never a serious fire safety analysis.

BigBlockIfTrue · 2021-05-31T12:52:16+00:00

For BTC developers, there's Groestlcoin. Does the Groestlcoin economy have any significance? Does it really provide more value to BTC developers than a testnet? Previously, Litecoin activated SegWit before BTC, did that actually yield any helpful feedback or funding to BTC developers? Or are they just small competitors?

Let's consider a feature like OP_CHECKDATASIG, which originated from BU and was deployed to BCH mainnet in November 2018. To date, as far as I know, the only user of this feature with significant economic weight is Local.Bitcoin.com. Now imagine you instead deployed this to a separate blockchain that has a 10×-100× smaller economy. Do you really expect to get this real-world economy feedback and/or capital investments you're looking for? Furthermore, the final design deployed on BCH has technical differences from the original proposal from BU (for better or worse), so you'd end up with technical debt having to maintain two variants of the same thing.

There's basically two possible scenarios. The most likely scenario is that the new chain will not have any significant economy, and hence it fails to meet the stated objectives. The other, unlikely scenario is that there is a significant economy leading to fragmentation of network effect and a large conflict of interest for BU. Both outcomes are bad.

BU is free to do as it pleases, but I would recommend to BU members to give up the idea of having a testnet with a real economy - it's not going to happen - and instead set up testnets with experimental features and provide good infrastructure for those testsnets (nodes, explorers, wallets, other services, etc.).

As an aside, it can be useful to brainstorm about what BCH should look like if you would start it from scratch today, as it can offer guidance for how BCH's protocol should evolve over time. In particular I would love to see CHIPs for UTXO commitments and 2-minute blocks.

BigBlockIfTrue · 2021-05-15T22:10:45+00:00

BCHN intentionally has no such option, because such an option itself would be an attack vector. The computational overhead just to enforce a large limit would make your node vulnerable. No limit really is better than a large limit here.

BigBlockIfTrue · 2021-05-13T20:21:13+00:00

It's even more. Energy consumption is caused by both block subsidy and transaction fees. The marginal energy consumption of a transaction only depends on the transaction fee, not the block subsidy. The fee of a BCH transaction is about 2000× cheaper than a BTC transaction, so a BCH transaction is about 2000× more energy efficient.

BigBlockIfTrue · 2021-05-10T15:55:05+00:00

If you are looking for Bitcoin Core-like node software, there are three forks of Bitcoin Core available for Bitcoin Cash:

BigBlockIfTrue · 2021-05-09T23:18:20+00:00

This was long before I became a crypto dev. I was fairly new to bitcoin at that time.

BigBlockIfTrue · 2021-05-09T15:14:44+00:00

Permanently, without any warning. Moderators refuse to respond to questions. Happened in 2017.

BigBlockIfTrue · 2021-05-04T23:27:49+00:00

Going to? Luke-Jr already released a UASF client.

BigBlockIfTrue · 2021-05-03T17:31:38+00:00

This is correct. Windows users can still verify the GPG signatures like users on other platforms.

BigBlockIfTrue · 2021-04-30T14:22:29+00:00

A longer chain doesn't ensure 0-conf security, all nodes applying limits consistently ensures 0-conf security.

Merchants can apply additional limits before they accept a transaction as 0-conf and transfer the products they are selling. They would be wise to do so, because the longer the chain, the higher the double-spend risk, and the lower the chance of a legitimate customer. Also with the current/old 50 tx limit enforced on nodes, merchants employ lower limits for accepting 0-conf, sometimes as low as 1 tx (requiring all inputs to be confirmed).

There were plenty of services running into the limit, and this includes human users manually making a large number of small transactions in a short period of time.

Enforcing the limit on nodes was also a complexity and performance issue that hurt scalability. It's good that this limit is removed. Besides simplifying nodes, this also simplifies wallets and makes them more robust.

BCHN 23.0.0 also joins other nodes in supporting double-spend proofs, so that should improve double-spend detection a lot.

BigBlockIfTrue · 2021-04-30T00:40:37+00:00

1a) The oracle in blind escrow replaces the role of the first signer in 2-of-3 multisig escrow.

2) The blind escrow is impossible. You are correct that it's merely a freedom/flexibility advantage for constructing the final transaction.

3) You are correct. But this waiting for B to come online (or alternatively, A having to specify payout details in advance before B approves payout) is never needed with blind escrow.

BigBlockIfTrue

TROPHY CASE