casascius,

It is already too late. Bech32 is used in the wild and reversing it would make much more mess than keeping it. And I personally believe this is a much cleaner solution than the withdrawn BIP142 https://github.com/bitcoin/bips/blob/master/bip-0142.mediawiki (addresses starting with letters? Come on)

If you mess up "1" and lowercase "l", the address will be invalid, so no real danger with confusing them. Yes, this is probably not the best what could have been designed but everything else is an improvement.

And you know that you can use bech32 all capitals?

You may be right about SPV nodes. So I could trick someone with a light node to think that he received BCash, while getting BClashic?

Nothing. The blocks are incompatible due to the difficulty difference. If you run BCash, BClashic blocks are invalid. And vice versa. Neither the length of the chain nor the accumulated proof of work matter. Nothing will happen after reaching these milestones.

The transactions are valid between the chains so they are replayed unless you have tainted coins that exist only in one of the chains. All the mined blocks after the split are tainted and all the coins that moved only in one of the chains. And all the coins that have tainted parents.

If this coin gets traded, it will be fun to watch the BCash narrative. Because it is not a fork of BCash, it's BCash that is a fork of BClashic

This coin is both hilarious and interesting. Interesting since it shows what can happen after a hard fork. Also because somebody used a lot of hashes to get to this point.

At the beginning, the difficulty was very high and a single miner mined several blocks. Since the fork, the network used 20000 Exahashes (if I haven't messed up the math), which if employed on the Bitcoin network, would bring at least 40 BTC. So somebody spent almost a million dollars of opportunity cost to bring this difficulty down and finally able to mine it like crazy (along with others). Who was such a nice sponsor?

The node memory usage is larger than the raw transactions size  due to some bookkeeping overhead. The sites report raw size while nodes have real usage limits. 300 MB standard limit is the real one, including the overhead and it has been crossed already, though it is slowly trending down (445 MB right now for my node).

There is no danger except a "danger" of large fees. Bitcoin Core will remove the low-paying transaction from the mempool so there is no way the memory gets exhausted. And actually, we crossed the 300 MB mark. My node (configured up to 600 MB) is currently at 490 MB usage.

Because there are no good ways to enforce it. And if you cannot enforce it, it's better not to have a false idea that there is such a rule. The current rule in the Core is that transactions older than 14 days are removed from the mempool. But you cannot be sure if anyone follows that rule.

Enforcing the rule would make it worse not better. Because you would have to remember that a certain transaction happened at certain time. And by doing that you are opening a possibility of a denial or service attack by flooding the network with many transactions. Currently if you flood the network, the nodes will remove the lowest-fee-per-byte transactions and you cannot exhaust the nodes memory.

In my humble opinion, this site works just like a site that sells "a rock that protects from tigers". They do nothing, in many cases the transaction will be confirmed, and in the worst case, they can refund the fee.



There is no such thing as hardcoded time limit in the distributed system. How you are going to enforce it? There is no common time, everybody sees everything differently. Somebody may see your transaction immediately. Somebody may see it later. The former group may forget about it but the latter will retransmit it. Somebody may store and retransmit the transaction just for fun. And you cannot ban retransmission. Otherwise, you won't be able to make the same transaction again. Moreover, storing a database of already transmitted transactions would by a DoS weak point. Somebody can flood the network and exhaust the memory of the nodes.

The current situation is the best one. Unless somebody double spends before the transaction is confirmed, the transaction should be considered final. Double spending is the only thing that can "reverse" a transaction.

It's not true. It's just a matter of fee per byte. Sure, a 226 byte transaction with a barely enough fee can fit into 999500 byte block while 10k will not but it is a cosmetic difference. If your fee is not worse than the transaction list sorted by fee at the 990000th-byte position, it will be mined. There are regularly >50kB transactions like thishttps://btc.com/1f2d5f70d409d3514de9f7c43bc6fc66863b450d18fff6abc068e72811588493 mined

It's incredible that this horribly broken site is still believed. The difficulty is going to drop 1-2% only. See, https://fork.lol/pow/retarget, or https://btc.com/stats/diff, or https://cryptothis.com/diff/.

ArtForz mined way more than 26,650 BTC. It was just his 9 week mining result when he started. He was likely responsible for roughly 25% of the total hashrate for a few months. With 7200 BTC per day (actually even more because the blocks were faster), let's say 180 days, he probably mined at least 300,000 BTC. But he sold most of his BTC and bought equipment from the sales and who knows how much BTC he left. Apart from being the first to GPU mine, he was also the first to mine with FPGAs and ASICs.  

GPU mining appeared roughly 1.5 years after the Bitcoin genesis block, in mid 2010. ArtForz was the first to use it (see ArtForz story here
http://www.ofnumbers.com/2014/04/20/how-artforz-changed-the-history-of-bitcoin-mining/) and indeed he did not go public but GPU public mining code appeared very shortly, see, eg.
https://bitcointalk.org/index.php?topic=1334.0. In late 2010/ early 2011 GPU mining was already dominating but CPU mining was still possible. First mining pools appeared in late 2010.
CPU mining stopped being profitable (although malware bots continued to mine it longer) roughly in Q2 2011.

You can do CPFP as a sender if you have the change and spending the change. But in this case, there was no change so only receiver can do CPFP.

Any wallet that allows spending unconfirmed inputs and selecting which inputs to spend. I know that Electrum can do it but there may be many more (Bitcoin Core can send it if the unconfirmed output is change). Electrum has even an extra  "child pays for parent" menu in the transaction tab that simplifies it.  

The best would be to use replace-by-fee but you have probably not done it.

I you own the output  1PyMz5LU7oGUeJwsanh3SGKPkc2vm66ntr, you can do "child pays for parent" https://bitcoin.org/en/glossary/cpfp. You spend from
1PyMz5LU7oGUeJwsanh3SGKPkc2vm66ntr  to another address you own and pay a large enough fee. The miners cannot confirm the child without confirming the parent so in order to grab the new fee, they have to confirm the parent transaction. The new transaction (1 input, one output) will be 192 bytes, so two transaction will be 10094+192=10286 bytes. You paid  41830 satoshi in fees. If you pay now a 100000 satoshi fee, these two transaction will be 141830/(10286)=13.78 satoshi/byte. Still not a lot, it will take many hours or days to confirm (but it would have been instant 1-2 days ago). If you pay 1,000,000 satoshis (0.01 BTC), the combined fee will be 1041830/10286=101.28 sat/byte which should get confirmed immediately (even 60-70 sat/byte should be fine now). See, the current mempool statistics:
https://core.jochen-hoenicke.de/queue/#2d
But 0.01 BTC is quite a lot. Your choice. During weekends, there are usually less transactions and mempool is usually emptier and the running fees are lower. Last weekend it was 5 sat/byte so your original transaction was very close.  But nobody knows how full the mempool will be.

It depends on the transaction size. For a typical, transaction with 1 input and 2 outputs (you have a coin, pay someone and get a change), the legacy virtual size is 225/226 bytes, so 10^6/226=4424 transactions. The same P2SH-P2WPKH segwit transaction is 166 virtual bytes, so 10^6/166=6024 transactions and for pure P2WPKH, the size is 141 vbytes, so 7092 transactions.

The blockchain is filled also with larger transaction (many inputs or multisignatures), so the number of transaction in the typical block is less but the saving are even better with multi inputs. Segwit saves most for multi input transactions, savings are minimal for multi output transactions.


Segwit transaction go to the same pool. But since they are effectively smaller (actually they are not but witness data goes to a different space that is larger than 1MB but one can operate on virtual size for which they are smaller), their fee per byte is larger if they pay the same fee. So they are ahead of the same legacy transactions paying the same fee. Or you can lower the fee and have the same probability of inclusion in the block as the legacy but with a smaller fee. Or choose any intermediate fee.

Maybe but it's not guaranteed. A node with longer timeout (or no timeout) can still keep your transaction and forward it to miners. There is nothing in the Bitcoin protocol related to timeout so a transaction after 14 day may or may not disappear from the mempools.

I'm not the owner of that site. It's just useful and probably the best one to analyze the mempool.

I don't have any other good site.  https://tradeblock.com/bitcoin/ used to work but it is not completely reliable.

Transaction per second is not a good measure of mempool status because transactions differ in size a lot. It's probably best to take a snapshot of the size of the  mempool at time t, compare to t+dt and add the size of blocks mined at that time.

People, please stop quoting blockchain.info. This site is broken. The transaction rate is smaller than the clearing rate, hence it cannot be 13 tps. I monitor it on my node and blockchain is completely bogus. See, https://jochen-hoenicke.de/queue/#24h for the correct data.

There is no "attack". Please stop spreading misinformation.

It happened but it has never happened at such scale, i.e. Bitcoin mining has never been that slow.