im_uname 20190729
Note: Other high-prioritiy projects like Reusable Addresses and Cashfushion exist. But the following parts can be done piecemeal, and many of the parts will also help Reusable Addresses.
Will recommend the following actions in order:
Note: This roadmap does not account for multisignature wallets (yet).
Derivative path autodetection; migrate to BIP39 default
##BCH reusable address
discussion sketch 20190602
@im_uname, with material from @marklundeberg and discussion with @cpacia
Goals in this version
Funds sent in one transaction - no setup (unless offline - see later sections)
| 20180807 ds_simulator preliminary test parameters and results | |
| Parameters: | |
| nodecount = 2000 | |
| minercount = 15 | |
| outgoing connections = 8 / node | |
| interval between tx1 and tx2 = 1 inventory cycle (~50ms for BU) | |
| loopcount = 200 (trials) |
Layer: Relay Policy Title: Standard Priority and Doublespend Proof Author: @im_uname <imaginary.username.btc@gmail.com>, Tom Zander <flowee@libertymail.net> Created: 2018-07-16 Last updated: 2018-08-09 License: IDGAF
A transaction may already have been propagated through all the network, or it may not yet be when a proof gets made. So a node that has both proof and (one of the) transaction in mempool can get asked by a peer to relay one or the other. When it gets asked to relay the transaction, it responds to relay both the transaction and the proof. If it gets asked the proof, it just gives the proof.
Now, this may cause bad use of bandwith as the proof may now be sent to a node twice. A simple solution might be to have a small message which essentially says "for the transaction you just requested, there is a double-spend proof with ID 'x'"
As such we introduce 3 parts to the network p2p layer of Bitcoin Cash.
I hereby claim:
To claim this, I am signing this object: