change client interface of wallets to redefine confirmation numbers.
zero conf, gone in UI interface except at sender client.
1 conf now means appearance in mempool in k (3 ? ) different mempools , plus a time delay of t seconds after initial receipt (2 seconds?) and no receipt of DSP proof.
2 conf in UI interface means 1 conf on block chain, 3 conf in UI means 2 blockchain confirmations, etc.
GUI interface at sender shows an orange checkmark at first successful broadcast, otherwise behaves much like other (recipient) wallets.
Recipient wallets show nothing until they have indication of receipt by the mempools of at least k nodes, plus a small delay after which no double spend proofs. This situation gives client GUIs a green checkmark and constitute the new 1 confirmation, i.e. mempool confirmation.
Once a transaction appears on the blockchain the GUI still shows a green checkmark. But extra transaction info can be provided at extra user actions primarily for debuggers or the paranoid.
The idea is to make it easy to see safe entry into mempool, difficult to see more by naive users. Note that the new 1 conf will be safe against everything except extreme DDoS attacks or miner collusion attacks.
This should not require changing any node software, just wallet software and possibly SPV server software. No consensus changes. The number of mempools require for mempool confirmation and the DSP timeout can be defaults of individual wallets and changed.
I want to propose a new message-reply, though. Full nodes today do not respond at all if the transaction that is submitted is simply accepted. On the other hand, full nodes send a reject message if it is not. So this means that anyone sending a transaction has to wait until they are certain no reject message is sent. Which is fragile. Ideally wallets can force a response that basically says something like: "Yes, txid is accepted at timestamp N"
Обсуждают сегодня