Thoughts on BUIP166
*This is a response to* *BUIP166, a Bitcoin Unlimited (BU) proposal to launch a new cryptocurrency**.* https://forum.bitcoinunlimited.info/t/buip-166-launch-a-new-cryptocurrency/35
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? https://www.groestlcoin.org/
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.
[This post on Reddit] https://old.reddit.com/r/btc/comments/np01it/wtf_bitcoin_unlimited_looking_forward_to_build/h02smap/
Bitcoin ABC (BCHA) Deep Reorganisation incident 29 March 2021
On 29 March 2021, Bitcoin ABC experienced a deep reorg. The following is a reconstruction of events, based on blockchain data.
Due to its low price compared to other bitcoin forks, the BCHA network has a rather low hashrate compared to the overall double-SHA256 mining market. A large majority of hashrate is controlled by one single pool: ZULUPooL. ZULUPooL is a merge-mining pool, which mines BCHA simultaneously with Hathor.
Like many blocks, block 679554 was merged-mined by ZULUPooL. However, from block 679555 onward, it appears that ZULUPooL had trouble with their merged-mining setup, and switched to an emergency non-merged-mining mode where it would just mine BCHA without mining Hathor. In this emergency mode, no transactions were included in the BCHA blocks, other than the coinbase transaction.
After a string of 13 empty blocks, all mined by ZULUPooL, ZULUPooL mined a second block at height 679555. Apparently their normal mining setup worked again: this block was merged-mined with Hathor and contains 15 BCHA transactions. The new block 679555 then got three confirmations from Mining-Dutch and one from ViaBTC. ZULUPooL then shifted more hashrate from the old chain to the new chain, even though it also kept mining the old chain in the supposed emergency mode.
Mining on the old chain completely stopped after 457 post-split blocks, so eventually the new chain is going to overtake the old chain in both block height and proof-of-work.
There was some speculation that the split was caused by ABC's reorg protection mechanism escalating a block race into an accidental chain split, but this is clearly not what happened. Instead, miners collectively decided to abandon a dozen blocks (which later became hundreds), for reasons we can only speculate. A possible reason is a community dislike of long strings of empty blocks, which led to a similar decision to perform a deep reorg in November 2020.
In conclusion, the reorg protection features worked as planned: they rejected the new chain replacing the old chain. However, reorg protection is obviously not going to be helpful if in fact BCHA's community repeatedly desires and approves deep reorgs.
CHIP-2021-03-12 Multiple OP_RETURNs for Bitcoin Cash
https://bitcoincashresearch.org/t/multiple-op-returns-this-time-for-real/315/12?u=bigblockiftrue
We would like to move forward with this CHIP rapidly, so please raise any issues quickly.
I am BigBlockIfTrue on noise.cash: https://noise.cash/u/BigBlockIfTrue
This conversation was marked as resolved
And no, when closing this conversation, the new coinbase rule was not removed from the BCH spec on bitcoincash.org. Of course not! Everyone clearly agrees with Jason here.
For specifications with actual community support, see here. https://upgradespecs.bitcoincashnode.org/2020-11-15-upgrade/
Bitcoin (Cash) historic and forecasted drift
These graphs show Bitcoin's and Bitcoin Cash's systematic deviation from the (purely) theoretical schedule of 10-minute blocks since genesis. They are similar to Jonathan Toomim's graph, but also shows the underlying mechanisms, and includes future drift induced by future hashrate increases. This drift estimation is based on Bitcoin's drift between 13 November 2017 and now, ASERT's drift being about 4.26× times smaller (assuming Bitcoin Cash and Bitcoin experience similar hashrate growth going forward), and the fact that Grasberg uses a variant of ASERT to target 11.25 minute block times until historic drift is corrected. As an indication of uncertainty, all graphs include an error bandwidth based on scenarios with ±75% drift. The uncertainty in block height translates into a much smaller uncertainty in coin supply, because every halving halves the sensitivity of supply to block height. Bitcoin Cash with ASERT and Bitcoin result in a nearly identical and well-predictable supply schedule for the future, while Bitcoin Cash with Grasberg suddenly takes a different turn. https://old.reddit.com/r/btc/comments/i0b54f/in_dec_2020_there_will_be_13_more_coins_in/ https://read.cash/@jtoomim/bch-upgrade-proposal-use-asert-as-the-new-daa-f67fff19 https://read.cash/@deadalnix/announcing-the-grasberg-daa-b09cbf30
As to whether that sudden monetary policy change is a good idea, I'll refer to noise's great article. https://read.cash/@noise/grasberg-will-weaken-the-sound-money-properties-of-bitcoin-cash-02789036
**BigBlockIfTrue statement on Read.cash meme ban threat**
I don't think it is helpful to threaten immediate bans and encourage self-censorship when this is frankly a grey area, despite the claimed simplicity of the rules. What one sees as legitimate criticism of someone's behaviour, someone else sees as a personal attack. Moreover, many memes are not ridiculing arbitrary people, but people in positions of power, and it would be absurd to ignore that.
I won't be deleting my cartoon since I do not see it as a personal attack. Now I just hope my account still exists tomorrow.
DAA development
BCH UX Recommendation: Mandatory CashAddr for P2SH
*This article was originally published on 9 January 2019 on* *Honest.cash**.* https://honest.cash/v2/BigBlockIfTrue/bch-ux-suggestion-mandatory-cashaddr-for-p2sh-1214
Background
Bitcoin Cash split from Bitcoin Core when the latter was about to activate SegWit. It also shared the same address format, and SegWit addresses are often in the pay-to-script-hash (P2SH) form (starting with *3*) that also works on Bitcoin Cash, but of course Bitcoin Cash doesn't actually support SegWit. This let to people accidentally sending BCH to SegWit addresses, creating a transaction output on the Bitcoin Cash chain that "anyone can spend", provided one knows the public key behind the script hash. Safe recovery of these BCH coins consequently required cooperation with a trusted miner, as it does not involve a signature.
As of January 2018, Bitcoin Cash has its own address for the P2SH format named CashAddr (starting with *q* or *p*) that does not work on Bitcoin Core. Meanwhile on Bitcoin Core, native SegWit addresses (starting with *bc1*) have become more popular, which are not in the P2SH form and thus do not work on Bitcoin Cash. These accidents have therefore become easier to avoid. However, because some Bitcoin Cash services have been slow or reluctant to switch to the new CashAddr format, many wallets still support sending BCH to addresses in the legacy format, which could potentially be SegWit addresses. The accidents can thus still happen. https://www.bitcoincash.org/spec/cashaddr.html
A plot twist
Perhaps surprisingly, the recent November 2018 upgrade of Bitcoin Cash made the problem worse. Namely, the BCH coins resulting from an accident are now "no-one can spend" instead of "anyone can spend", so even a trusted miner can no longer recover them for you. This is a side effect of the new clean stack rule that partially solves third-party malleability. https://www.bitcoincash.org/spec/2018-nov-upgrade.html
Third-party malleability is a man-in-the-middle attack where any relay node can modify some parts of the contents of a transaction as it gets relayed, without involvement of the sender, receiver, or even miners. This complicates handling 0-conf transactions and is obviously something we want to solve, but now some people fear about loss of BCH coins in SegWit accidents and consider reversing the rule change. https://youtu.be/_ermlxBgPC4?t=261
The sustainable solution
The much simpler and much more sustainable solution to this problem is to end the SegWit accidents once and for all. I think this is surprisingly easy:
**Refuse sending BCH transactions to addresses starting with a** ***3*****.**
Bitcoin Cash services that don't yet support CashAddr likely use pay-to-public-key-hash (P2PKH) legacy addresses (starting with *1*). These have no risk of SegWit accidents and wallets can continue to accept them as inputs. The most common use case of P2SH (starting with *3*) other than SegWit is legacy multi-signature wallets, but their usage is relatively rare, especially for hot wallets. Refusing sending transactions to addresses starting with *3* will thus have minimal impacts on backward compatibility, while it completely eliminates SegWit accidents.
So, in short:
**Bitcoin Cash wallets** should refuse sending funds to P2SH addresses in legacy format (starting with *3*). Any option to override this should be hidden in advanced wallet settings where no noob can accidentally disable this safeguard.
**Bitcoin Cash address convertors** should warn to not send funds to P2SH addresses converted from legacy format (starting with *3*) to CashAddr format (starting with *p*). Such address conversion should only be used to analyse transaction history, not for creating new transactions.
In rare cases **Bitcoin Cash users** still encounter P2SH addresses in legacy format (starting with *3*), they should ask for an address in CashAddr format before sending any funds.
This allows Bitcoin Cash to move forward without risking irrecoverable loss of funds.
Known implementations
Electron Cash https://github.com/Electron-Cash/Electron-Cash/issues/1658#issuecomment-549297013
Crescent Cash https://twitter.com/crescentcash/status/1191767504517025793
There is no such thing as permissionless transfer of redeemable tokens
*This article was originally published in 2018 on* *Yours.org**.* https://www.yours.org/content/7c1714cff413
I've watched a large part of the July 5th discussion on the GROUP proposal for tokens on Bitcoin Cash, which sort-of devolved into Andrew Stone and Emil Oldenburg versus (most of) the rest. I think I've figured out the fundamental argument why "the rest" opposes GROUP, which surfaced roughly halfway the video and I'll explain below. https://www.youtube.com/watch?v=ZwhsKdXRIXI https://docs.google.com/document/d/1X-yrqBJNj6oGPku49krZqTMGNNEWnUJBRFjX7fJXvTs/edit
The only trustless token is a non-redeemable token
The landscape of possible token use cases can roughly be divided into tokens that are redeemable for something and tokens that are not. I'll focus on the former first.
Naturally, a redeemable token inherently requires trust that the token will be redeemed by its issuer. The primary argued benefit of the GROUP proposal compared to non-protocol-layer alternatives like Tokeda, is that GROUP can remove some of the trust, by (optionally) removing some of the token management duties from the issuer and simply letting Bitcoin Cash miners handle things. http://media.lokad.com/bitcoin/tokeda-2018-04-30.pdf
One particular example recurring in the discussion is the approval of transactions. With Tokeda, the token issuer (or delegate thereof) must approve every transaction involving the token, whereas with GROUP, it is possible to remove the token issuer from this process and leave it entirely to the miners. Thus, it is argued, we no longer need to trust the issuer with the processing of transactions.
...But did we really remove any trust at all?
We are talking about redeemable tokens here. If the issuer disagrees with a transaction, he can simply track the transacted token from there on and refuse to redeem it later, thereby invalidating the transaction after-the-fact. This is not just theoretical; it is exactly what Tether did when funds where stolen from its treasury. https://archive.is/ZFDBf
You can try to hard-code rules with GROUP all you want, you can scream "code is law" all you want, you can have miners validate rules all you want, you can point to what transaction is in the blockchain all you want, but at the end of the day, the issuer can always change any rule he wants, even retroactively. He who controls the redemption process, controls the token - this is an unavoidable economic truth. All your base are belong to the issuer; face it and deal with it. A token cannot possibly be more decentralised than the number of places it can be redeemed. A redeemable token cannot have permissionless transactions by its very nature. And if the issuer does not redeem what is rightfully yours, it is always you who has to file a lawsuit.
Issuers freezing tokens is actually a good thing
Once you understand that no matter what, the issuer can refuse transactions anyway, it makes no sense to make futile attempts to prevent this.
While not mentioned in the discussion, when you think about it, it is actually a good thing that the issuer always validates token transactions. If the issuer is not going to redeem a particular token, it's better for the ecosystem if we know it as soon as possible. Specifically, having the issuer approve token transactions has the following advantages:
It means you immediately know whether the issuer accepts the transaction, instead of only finding out much later when one tries to redeem the transacted token.
It means that when you receive a valid token, the issuer explicitly acknowledges your ownership of it, i.e. your right to redeem. This e.g. avoids the need for exchanges to check deposited tokens against a blacklist that must be kept up-to-date.
It means that if someone tries to send you an invalid token, you are immediately aware that it's worthless. (In the video, Oldenburg complains "but then the value would immediately drop to zero...", which is exactly what the value of an unredeemable redeemable token is supposed to do.)
It means that invalid tokens are removed from circulation immediately, instead of lingering in the hands of unaware bagholders.
It means the entire userbase of the token can immediately detect when the issuer refuses any transaction.
It means token transactions automatically stop when its issuer ceases operation, preventing useless transaction load on the blockchain (part of Ethereum's congestion problem).
It means transactions can be paused when the issuer has technical problems.
The capability to freeze tokens is not a burden on the issuer either. If the issuer does not care about transactions, he only needs to run a full node that automatically approves all token transactions it sees. For the really non-technical, this task can be trustlessly delegated to a specialised organisation that potentially manages lots of tokens simultaneously.
A protocol change for a hypothetical Caribbean island
Of course, there is still the case of tokens that are non-redeemable by design, i.e. tokens that intend to be a decentralised currency. These use cases seem to be very rare however. Usually, one can simply use BCH directly for such purposes. (Note that transaction fees are paid in BCH in all proposals.)
One other example use case in the non-redeemable category mentioned during the discussion is a small country, e.g. a Caribbean island, that wants to put its national currency on the Bitcoin Cash blockchain. This is completely hypothetical however, and hardly a reason to change the Bitcoin Cash protocol with GROUP now.
Overall, GROUP is thus an (arguably complex) protocol change proposed to remove trust compared to non-protocol-layer solutions, but in the vast majority of imaginable token use cases (redeemable tokens) it provides no clear advantage. In my opinion, "the rest" was rightfully pushing back against GROUP in the discussion. For now, we are probably better off further developing (software for) non-protocol-layer token solutions, and stop making the mistake to consider those second-class solutions.
Bitcoin Cash
BigBlockIfTrue, 2020
Online API documentation for Bitcoin Cash Node
Good news for Bitcoin Cash developers! Two sets of Bitcoin Cash Node API documentation are now published on the project website:
**Command-line interface documentation** https://docs.bitcoincashnode.org/cli/bitcoind/
**JSON-RPC interface documentation** https://docs.bitcoincashnode.org/json-rpc/
I wrote code to automatically generate these webpages from CLI/RPC help text embedded in the application. I also integrated this code into the release process of the software, so that the webpages will automatically stay up-to-date as new versions are released. The source for the webpages is also available as Markdown files in the Bitcoin Cash Node git repository - Dagur and merc1er set up the system that converts the Markdown files into a website. https://gitlab.com/bitcoin-cash-node/bitcoin-cash-node/-/tree/master/doc
The contents of the pages should be familiar, but now you can easily access them without diving into the command line, and enjoy nicer formatting. However, I also made a series of improvements to the contents. The most notable changes are:
I wrote a help text for the command-line options that were previously undocumented.
I made hidden aliases of command-line options visible in the help text.
I improved and extended the help text for various command-line options.
I changed the categories of various command-line options for consistency.
I made the reorg protection RPC commands visible in the RPC commands list.
I removed SegWit references from RPC help text.
No project funds have been used for this effort, but I hope (and am confident) you will enjoy the improved and online API documentation like myself. If you do, tips are appreciated (BigBlockIfTrue#54916; ☯). Happy developing and also enjoy the pending release of Bitcoin Cash Node v0.21.2!
Fear, Uncertainty, and Doubt
Peter Rizun repeatedly emphasises that he wants "P2P ecash", and he only supports Bitcoin Cash (BCH) because it is "the most promising means of achieving that end". https://twitter.com/PeterRizun/status/1199446780670181376
His latest Twitter poll is a manifestation of this. In addition to BTC and BCH as two implementations of the "P2P ecash" idea - with differing degrees of success - Rizun feels the need to explicitly offer the generic idea of "P2P ecash" as a third option besides the two implementations.
https://twitter.com/PeterRizun/status/1215693874426810373
But perhaps indicative of why BTC's market price has so far outperformed BCH's, by artificially splitting the vote between BCH and "P2P ecash", BTC defeats BCH. When someone comments the obvious - BCH and "P2P ecash" are the same - he tries to convince this person they should vote "P2P ecash" and not BCH. What purpose does this serve? Surely BCH would have won this poll without this third option. Backing BCH would actually advance the realisation of "P2P ecash".
There is no indication BTC will increase its block size limit. There is no indication BCH will cease being peer-to-peer electronic cash. There is no indication BCH cannot overcome attacks. There is no indication BCH developers are malicious. There is no indication BCH users will be unable to escape any malicious developers by forking away from them. There is no indication BCH users will be unable to escape any evil miners by changing proof-of-work. There is no indication Bitcoin Unlimited itself will be unable to fund development of BCH or any future fork thereof.
It took me some time to realise, but essentially it's all fear, uncertainty, and doubt - FUD. Leaders of Bitcoin Unlimited, and thereby leaders of Bitcoin Cash, should seek to remove FUD about the project, not create it. And since even Rizun acknowledges BCH is the most promising realisation of "P2P ecash", he is scoring an own goal every time he pushes this argument.
Because those who would give up Bitcoin Cash (BCH) to pursue "bitcoin as a peer-to-peer electronic cash system", deserve neither and will lose both.
Can you steal bitcoins?
There is some discussion in the Bitcoin Cash community whether bitcoin itself (i.e. BCH) could qualify as money. Amaury Séchet clearly believes it does - in his famous speech announcing the Bitcoin Cash project, he even said it's the best money ever. On the other side of the debate, Vin Armani claims bitcoin is not money. Somewhere in between there is Tobias Ruck's position that improving bitcoin's intrinsic utility will improve its chance of becoming money - which we can probably all agree with. https://www.youtube.com/watch?v=By0w43NQdiY https://twitter.com/vinarmani/status/1159832228567736326 https://read.cash/@TobiasRuck/why-mises-would-love-mitra-bitcoin-cashs-hidden-superpower-that-even-ethereum-20-doesnt-have-34a3261b
One of Vin Armani's arguments is this: https://twitter.com/vinarmani/status/1214279366726676480
[...] you can't own bitcoins.
If you can't make a valid ownership claim on an item (it can't be stolen), can that item be money?
But is it really true that bitcoin cannot be stolen?
The RuneScape case
In the Netherlands, a landmark legal judgement on theft of virtual items is known as "the Runescape judgement". In this case, victim and suspects all play the computer game RuneScape. While the 13-year-old victim is cycling home in September 2007, the suspects (also on bicycles) force him to go home with them. Once arrived, the victim is forced to transfer money and goods from his RuneScape account to an account of the suspects. He refused, prompting the suspects to physically assault him and make a death threat. The victim gives in and logs in to his account, after which suspects beat him again, and then transfer the virtual money and goods to themselves. https://nl.wikipedia.org/wiki/Arrest_RuneScape
Police arrests the suspects next day. They are charged with violent theft, assault, and threat. The court indeed convicts them of violent theft. The main suspect appeals.
Court of appeal
In appeal, the defence presents the following arguments against conviction:
*The removed objects intangible and immaterial.* The court of appeal rejects this, citing a 1921 Supreme Court ruling on electricity theft to show there is no requirement of materiality for a theft conviction - its economic value is considered more important.
*The removed objects have no economic value.* The court of appeal rejects this too, citing earlier decisions that its value to the owner also counts here. The victim as well as both suspects all made statements indicating the objects have value and effort was put into creating them.
*The victim does not own the objects, but merely has a licence to use them.* The appeals court rejects this argument as not only an owner but also a mere controller of an object is a victim of theft, when a thief takes over control. The verdict uses a comparison with passport theft: a passport is owned by the state but controlled by the holder, and can be stolen from the holder.
The court of appeal further points out:
The removal of the virtual objects happened outside the scope of the rules of the virtual world, i.e. the removal happened outside of the game.
Suspects did not just gain control of the objects, but the victim also lost control. This distinguishes theft from illegal copying of computer data.
As you might have guessed, the court of appeal also convicts the suspect. But the defence files a cassation appeal. On to Supreme Court!
Supreme Court
In Supreme Court, the defence makes three arguments:
*The removed objects are not real, they're just an illusory rendering of bits and bytes.* Supreme Court disagrees, with the defence failing to demonstrate that the court of appeals made an unsound judgement on this aspect (considering valuation, creation through effort, or lost control).
*The law classifies the objects as data.* Supreme Court rules that being data and being stealable need not be mutually exclusive.
*Taking in-game objects from other players is fair game.* Supreme Court rejects this argument as the court of appeals correctly ruled the game rules do not account for the method used by suspects.
And thus the appeal to Supreme Court also fails. The end.
Implications for Bitcoin
So what are the likely implications for any bitcoin 'removal' in the Netherlands?
Bitcoin obviously has value (the market price) and is created through effort (proof-of-work mining).
Section 2 of the whitepaper indicates bitcoin can be owned. But even regardless of ownership, the holder of the private key clearly controls the bitcoin.
Due to double-spending being prohibited, victims of bitcoin removal clearly lose control of their bitcoin.
Bitcoin consensus rules do not account for transfer through illegally removed/copied private keys. One might even argue that the whitepaper describes bitcoin as a 'cash system', and removing someone's control of cash tends to violate the rules implied by a cash system. Without accounting for private key removal/copying, Section 6 of the whitepaper explicitly describes 'stealing' and 'play[ing] by the rules' as opposites.
Whether bitcoin is classified as data is not relevant.
In other words, removing bitcoin through illegal acquisition of private keys is most certainly criminal theft, consistent with several rulings on theft of other virtual items after this landmark RuneScape case. Likewise, the public prosecutor can confiscate bitcoin similar to physical items. https://blog.iusmentis.com/2014/07/23/inbeslagname-van-criminele-bitcoins/
However, *I can* invoke the fair-game criterion for my Grand Theft Read.Cash. https://read.cash/@BigBlockIfTrue/grand-theft-readcash-3f13fb46
*I am not a lawyer. This is not legal advice.*
Grand Theft Read.Cash
Earlier today, the people behind Read.Cash drafted a proposal for a smart contract allowing password-based wallet recovery. I think this has both positive and negative aspects. I like the general idea of ... https://read.cash/@Read.Cash/recoverable-bitcoin-cash-wallets-2918c893
The tools
Bitcoin ABC (required, blockchain history not needed) https://www.bitcoinabc.org/
text editor (required)
Electron Cash (optional) https://electroncash.org/
Mission Impossible theme music (optional)
The plan
**Step 1.** Use Electron Cash to generate a receiving address for the booty. Upon success, Electron Cash will automatically initiate CashShuffle for the perfect getaway. I generated `bitcoincash:qpq9y25eejhx7pdk53eul93r563v68jz4s4stdkf5j`. Alternatively, use the wallet within Bitcoin ABC, but then the treasure remains traceable. https://electroncash.org/ https://cashshuffle.com/
**Step 2.** Bitcoin ABC comes with an optional command-line utility `bitcoin-tx` to construct transactions. You can find it in the `bin` directory. Summon its manual: https://www.bitcoinabc.org/
$ bitcoin-tx -?
Bitcoin ABC bitcoin-tx utility version v0.20.6-unk
Usage: bitcoin-tx [options] <hex-tx> [commands] Update hex-encoded bitcoin transaction
or: bitcoin-tx [options] -create [commands] Create hex-encoded bitcoin transaction
Options:
-?
This help message
-create
Create new, empty TX.
-json
Select JSON output
-txid
Output only the hex-encoded transaction id of the resultant transaction.
Chain selection options:
-testnet
Use the test chain
Commands:
delin=N
Delete input N from TX
delout=N
Delete output N from TX
in=TXID:VOUT(:SEQUENCE_NUMBER)
Add input to TX
locktime=N
Set TX lock time to N
nversion=N
Set TX version to N
outaddr=VALUE:ADDRESS
Add address-based output to TX
outdata=[VALUE:]DATA
Add data-based output to TX
outmultisig=VALUE:REQUIRED:PUBKEYS:PUBKEY1:PUBKEY2:....[:FLAGS]
Add Pay To n-of-m Multi-sig output to TX. n = REQUIRED, m = PUBKEYS.
Optionally add the "S" flag to wrap the output in a
pay-to-script-hash.
outpubkey=VALUE:PUBKEY[:FLAGS]
Add pay-to-pubkey output to TX. Optionally add the "S" flag to wrap the
output in a pay-to-script-hash.
outscript=VALUE:SCRIPT[:FLAGS]
Add raw script output to TX. Optionally add the "S" flag to wrap the
output in a pay-to-script-hash.
sign=SIGHASH-FLAGS
Add zero or more signatures to transaction. This command requires JSON
registers:prevtxs=JSON object, privatekeys=JSON object. See
signrawtransactionwithkey docs for format of sighash flags, JSON
objects.
Register Commands:
load=NAME:FILENAME
Load JSON file FILENAME into register NAME
set=NAME:JSON-STRING
Set register NAME to given JSON-STRING
**Step 3.** Figure out what coin you want to steal. In this case, the mission is output 1 (count from zero) of transaction b48e260f36142340cc1652bbc2da5028303e21f469d169393d3b08f234165dfc, worth 0.02290635 BCH. https://blockchair.com/bitcoin-cash/transaction/b48e260f36142340cc1652bbc2da5028303e21f469d169393d3b08f234165dfc
**Step 4.** Create the transaction, ignoring the amount of the output for a moment:
$ bitcoin-tx -json -create in=b48e260f36142340cc1652bbc2da5028303e21f469d169393d3b08f234165dfc:1 outaddr=0:qpq9y25eejhx7pdk53eul93r563v68jz4s4stdkf5j
{
"txid": "d0dc399a668008fa6a0bebc0680ba16d3ca33187fa0ea37adf7a5a367f330dbd",
"hash": "d0dc399a668008fa6a0bebc0680ba16d3ca33187fa0ea37adf7a5a367f330dbd",
"version": 2,
"size": 85,
"locktime": 0,
"vin": [
{
"txid": "b48e260f36142340cc1652bbc2da5028303e21f469d169393d3b08f234165dfc",
"vout": 1,
"scriptSig": {
"asm": "",
"hex": ""
},
"sequence": 4294967295
}
],
"vout": [
{
"value": 0.00000000,
"n": 0,
"scriptPubKey": {
"asm": "OP_DUP OP_HASH160 40522a99ccae6f05b6a473cf9623a6a2cd1e42ac OP_EQUALVERIFY OP_CHECKSIG",
"hex": "76a91440522a99ccae6f05b6a473cf9623a6a2cd1e42ac88ac",
"reqSigs": 1,
"type": "pubkeyhash",
"addresses": [
"16s6gJN1t7yPZGfzUFvMo9xkFvN7MzjkHH"
]
}
}
],
"hex": "0200000001fc5d1634f2083b3d3969d169f4213e302850dac2bb5216cc402314360f268eb40100000000ffffffff0100000000000000001976a91440522a99ccae6f05b6a473cf9623a6a2cd1e42ac88ac00000000"
}
**Step 5.** You see the `scriptSig` field of the input, the signature script that authorises spending the input, is still missing. Since the coin we're stealing is a Pay-to-Script-Hash (P2SH) coin, the signature script consists of the unhashed P2SH script (`b251f93c45baea5c72bae18311c75eccad404291 OP_OVER 'read.cash' OP_EQUAL OP_NIP OP_NIP`), preceded by all other input data to this P2SH script itself (again the password 'read.cash'):
Password length (9) push operation: 09
Password: 726561642e63617368
Unhashed P2SH script length (35) push operation: 23
Unhashed P2SH script: 14b251f93c45baea5c72bae18311c75eccad4042917809726561642e63617368877777
Full signature script:
09726561642e636173682314b251f93c45baea5c72bae18311c75eccad4042917809726561642e63617368877777
**Step 6.** Our signature script is 46 bytes long, or 47 bytes including a 1-byte length indicator prefix (`2e`). This must replace the 0-byte signature script with 1-byte length indicator (`00`) in our transaction template. The transaction will therefore grow from 85 bytes to 131 bytes. With the minimum fee rate of 1 sat/b, we thus need to attach a fee of 0.00000131 BCH, so we can claim 0.02290504 BCH for ourselves. Generate a new transaction template accordingly:
$ bitcoin-tx -json -create in=b48e260f36142340cc1652bbc2da5028303e21f469d169393d3b08f234165dfc:1 outaddr=0.02290504:qpq9y25eejhx7pdk53eul93r563v68jz4s4stdkf5j
{
"txid": "0229cef50d62eff07dd7133ce9db29364c46866b0b46f8437f58bf3e2012318e",
"hash": "0229cef50d62eff07dd7133ce9db29364c46866b0b46f8437f58bf3e2012318e",
"version": 2,
"size": 85,
"locktime": 0,
"vin": [
{
"txid": "b48e260f36142340cc1652bbc2da5028303e21f469d169393d3b08f234165dfc",
"vout": 1,
"scriptSig": {
"asm": "",
"hex": ""
},
"sequence": 4294967295
}
],
"vout": [
{
"value": 0.02290504,
"n": 0,
"scriptPubKey": {
"asm": "OP_DUP OP_HASH160 40522a99ccae6f05b6a473cf9623a6a2cd1e42ac OP_EQUALVERIFY OP_CHECKSIG",
"hex": "76a91440522a99ccae6f05b6a473cf9623a6a2cd1e42ac88ac",
"reqSigs": 1,
"type": "pubkeyhash",
"addresses": [
"16s6gJN1t7yPZGfzUFvMo9xkFvN7MzjkHH"
]
}
}
],
"hex": "0200000001fc5d1634f2083b3d3969d169f4213e302850dac2bb5216cc402314360f268eb40100000000ffffffff0148f32200000000001976a91440522a99ccae6f05b6a473cf9623a6a2cd1e42ac88ac00000000"
}
**Step 7.** To complete the transaction, the signature script must be inserted into the transaction template manually. To do so, copy and paste the hexadecimal representation of the transaction into a text editor. Use the transaction format documentation to decode it and find the right place for inserting the signature: https://bitcoin.stackexchange.com/a/72708 https://en.bitcoin.it/wiki/Transaction
Version number (2): 02000000
Number of inputs (1) as varint: 01
Parent transaction: fc5d1634f2083b3d3969d169f4213e302850dac2bb5216cc402314360f268eb4
Parent transaction output index (1): 01000000
Signature script length (0) as varint: 00
Remainder of transaction: ffffffff0148f32200000000001976a91440522a99ccae6f05b6a473cf9623a6a2cd1e42ac88ac00000000
**Step 8.** Replace the zero-length signature script with the actual signature script constructed earlier:
Version number (2): 02000000
Number of inputs (1) as varint: 01
Parent transaction: fc5d1634f2083b3d3969d169f4213e302850dac2bb5216cc402314360f268eb4
Parent transaction output index (1): 01000000
Signature script length (46) as varint: 2e
Signature script: 09726561642e636173682314b251f93c45baea5c72bae18311c75eccad4042917809726561642e63617368877777
Remainder of transaction: ffffffff0148f32200000000001976a91440522a99ccae6f05b6a473cf9623a6a2cd1e42ac88ac00000000
Full transaction: `0200000001fc5d1634f2083b3d3969d169f4213e302850dac2bb5216cc402314360f268eb4010000002e09726561642e636173682314b251f93c45baea5c72bae18311c75eccad4042917809726561642e63617368877777ffffffff0148f32200000000001976a91440522a99ccae6f05b6a473cf9623a6a2cd1e42ac88ac00000000`
**Step 9.** Verify that the resulting transaction looks alright:
$ bitcoin-tx -json 0200000001fc5d1634f2083b3d3969d169f4213e302850dac2bb5216cc402314360f268eb4010000002e09726561642e636173682314b251f93c45baea5c72bae18311c75eccad4042917809726561642e63617368877777ffffffff0148f32200000000001976a91440522a99ccae6f05b6a473cf9623a6a2cd1e42ac88ac00000000
{
"txid": "b73ad30dcba9ed29512ae2c8ea23d6c6bfd8786042e1347938b96e1b296b1f2c",
"hash": "b73ad30dcba9ed29512ae2c8ea23d6c6bfd8786042e1347938b96e1b296b1f2c",
"version": 2,
"size": 131,
"locktime": 0,
"vin": [
{
"txid": "b48e260f36142340cc1652bbc2da5028303e21f469d169393d3b08f234165dfc",
"vout": 1,
"scriptSig": {
"asm": "726561642e63617368 14b251f93c45baea5c72bae18311c75eccad4042917809726561642e63617368877777",
"hex": "09726561642e636173682314b251f93c45baea5c72bae18311c75eccad4042917809726561642e63617368877777"
},
"sequence": 4294967295
}
],
"vout": [
{
"value": 0.02290504,
"n": 0,
"scriptPubKey": {
"asm": "OP_DUP OP_HASH160 40522a99ccae6f05b6a473cf9623a6a2cd1e42ac OP_EQUALVERIFY OP_CHECKSIG",
"hex": "76a91440522a99ccae6f05b6a473cf9623a6a2cd1e42ac88ac",
"reqSigs": 1,
"type": "pubkeyhash",
"addresses": [
"16s6gJN1t7yPZGfzUFvMo9xkFvN7MzjkHH"
]
}
}
],
"hex": "0200000001fc5d1634f2083b3d3969d169f4213e302850dac2bb5216cc402314360f268eb4010000002e09726561642e636173682314b251f93c45baea5c72bae18311c75eccad4042917809726561642e63617368877777ffffffff0148f32200000000001976a91440522a99ccae6f05b6a473cf9623a6a2cd1e42ac88ac00000000"
}
**Step 10.** Start the Bitcoin ABC node. Open the debug window via the help menu and go to the console tab. Read the scammer warning and laugh evilly, because this time you are the criminal. Then, summon the command list:
$ help
== Blockchain ==
(...)
== Control ==
(...)
== Generating ==
(...)
== Mining ==
(...)
== Network ==
(...)
== Rawtransactions ==
combinepsbt ["psbt",...]
combinerawtransaction ["hexstring",...]
converttopsbt "hexstring" ( permitsigdata )
createpsbt [{"txid":"id","vout":n},...] [{"address":amount},{"data":"hex"},...] ( locktime )
createrawtransaction [{"txid":"id","vout":n},...] [{"address":amount},{"data":"hex"},...] ( locktime )
decodepsbt "psbt"
decoderawtransaction "hexstring"
decodescript "hexstring"
finalizepsbt "psbt" ( extract )
fundrawtransaction "hexstring" ( options )
getrawtransaction "txid" ( verbose "blockhash" )
sendrawtransaction "hexstring" ( allowhighfees )
signrawtransactionwithkey "hexstring" ["privatekey1",...] ( [{"txid":"id","vout":n,"scriptPubKey":"hex","redeemScript":"hex"},...] sighashtype )
testmempoolaccept ["rawtxs"] ( allowhighfees )
== Util ==
(...)
== Wallet ==
(...)
**Step 11.** Find the transaction broadcast command `sendrawtransaction` and look up how it works:
$ help sendrawtransaction
sendrawtransaction "hexstring" ( allowhighfees )
Submits raw transaction (serialized, hex-encoded) to local node and network.
Also see createrawtransaction and signrawtransactionwithkey calls.
Arguments:
1. "hexstring" (string, required) The hex string of the raw transaction)
2. allowhighfees (boolean, optional, default=false) Allow high fees
Result:
"hex" (string) The transaction hash in hex
Examples:
Create a transaction
> bitcoin-cli createrawtransaction "[{\"txid\" : \"mytxid\",\"vout\":0}]" "{\"myaddress\":0.01}"
Sign the transaction, and get back the hex
> bitcoin-cli signrawtransactionwithwallet "myhex"
Send the transaction (signed hex)
> bitcoin-cli sendrawtransaction "signedhex"
As a json rpc call
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "sendrawtransaction", "params": ["signedhex"] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/
**Step 12.** Now go for it. Don't let your dreams be dreams. Join the dark side. Commit the crime:
$ sendrawtransaction 0200000001fc5d1634f2083b3d3969d169f4213e302850dac2bb5216cc402314360f268eb4010000002e09726561642e636173682314b251f93c45baea5c72bae18311c75eccad4042917809726561642e63617368877777ffffffff0148f32200000000001976a91440522a99ccae6f05b6a473cf9623a6a2cd1e42ac88ac00000000
Alea iacta est. If the heist succeeds, Electron Cash will quickly detect an incoming transaction. But since the transaction has no cryptographic signature, the booty can still be stolen by a miner even more evil than you - until the transaction is confirmed. Electron Cash will then CashShuffle the proceeds to make it untraceable. Just make sure to avoid spending the shuffled coins together. https://blockchair.com/bitcoin-cash/transaction/b73ad30dcba9ed29512ae2c8ea23d6c6bfd8786042e1347938b96e1b296b1f2c https://honest.cash/v2/BigBlockIfTrue/blockchain-analysis-versus-cashshuffle-tracking-the-300-bch-donation-to-bitcoin-unlimited-5153
Proof of success
Message: `All Read.cash's $5 are belong to BigBlockIfTrue!`
Address: `qpq9y25eejhx7pdk53eul93r563v68jz4s4stdkf5j`
Signature: `IDuoVZb/0Qm+TAaKMdvf4wbR0WvW/iq1zwN3VwYqf4xSDVY9kxfN3cu3pJ2rnbufmvbjntP9T+eAQ1suPPZIHDw=`
Achievement unlocked: Bitcoin Cash fixed all common third-party transaction malleation vectors
**Canonically encoded ECDSA signatures**: Non-DER encoded ECDSA signatures are prohibited since the activation of BIP 66 in July 2015.
**Non-push operations in scriptSig**: Non-push operations in signature scripts are prohibited since the November 2018 Bitcoin Cash network upgrade. Bitcoin Core still accepts them.
**Push operations in scriptSig of non-standard size type**: Non-standard-size push operations in any script are prohibited since the November 2019 Bitcoin Cash network upgrade. Bitcoin Core still accepts them.
**Zero-padded number pushes**: Processing numbers encoded in non-standard form is prohibited since the November 2019 Bitcoin Cash network upgrade. Bitcoin Core still accepts this.
**Inherent ECDSA signature malleability**: High S values in ECDSA signatures are prohibited since the November 2017 Bitcoin Cash network upgrade. Bitcoin Core still accepts them.
**Malleability of failing signature**: Passing invalid signatures other than null to OP_CHECK(MULTI)SIG is prohibited since the November 2017 Bitcoin Cash network upgrade. Bitcoin Core still continues script execution.
**Superfluous scriptSig operations**: Script execution must result in a clean stack since the November 2018 Bitcoin Cash network upgrade. Bitcoin Core does not require this. The May 2019 Bitcoin Cash network upgrade adds an exemption only for specific SegWit-like signature scripts.
**Inputs ignored by scripts**: The second input of OP_CHECKMULTISIG(VERIFY) is no longer ignored since the November 2019 Bitcoin Cash network upgrade. Instead, on Bitcoin Core this input is required to be null since the activation of BIP 147 in August 2017.
@BigBlockIfTrue
