@electrumsv is on PowPing!

PowPing is a place where you can earn Bitcoin simply by socializing, for FREE.
Never tried Bitcoin? It's OK! Just come, socialize, and earn Bitcoin.
Check out electrumsv's activities
Total Economy: 0 USD

Notes on UTXO refactoring

These are transcribed notes for the next refactoring pass at ElectrumSV's UTXO management and coin management, maybe some people will find them interesting and have suggestions..


One thing we need to reconcile in the upcoming refactoring of UTXOs is better and more correct transaction processing.

Here was the problem situation that we encountered:

  1. The user signs a transaction that uses a set of inputs. It is local and not broadcast.
  2. The external seed using application does not know about this and constructs a transaction that uses some of the same inputs, but also some others. When the wallet incorporates it, it does not notice that it is only claiming those of the inputs that are not assigned in (1).
  3. So now the transaction from (1) is deleted and (2) still does not claim the inputs that it uses that were in (1).

Now what we should do in that situation is reject (2) and allow the user to know and react in some way. However, this also relates to another problem, where we do not have enough transaction state in the database, specifically we do not store the spent outpoints for a transaction. If we want to locate those we need to load and reparse a transaction.

We should have both (1) and (2) in the database, both inputs and outputs. But now we need to differentiate between outputs that are recognized as active by an account, and those which are not. Oh, and implicit in this is that we need to move away from process key usage being driven by indexer state

I was using Electron Cash and you could change server, and your transaction history would change according to the server state. So if the server had a local node that accepted the low fee tx, it would resync and show those. But if you switched to a server with a local node with high minimum fee then it would resync and remove these. ElectrumSV should use services but be server-less, a final move away from this legacy server authoritativeness is a move towards P2P.

To recap, there are three additional goals beyond the above:

  1. Try and remove UTXO caching in the Python layer so we can use database queries without worrying about race conditions because of state differences due to update latency.
  2. Optimise coin selection so there is minimal friction to concurrent transaction creation.
  3. Manage change for privacy and security, where there is a maximum coin size, and change selection is using Benford's law driven coin sizing.

How far we can get towards p2p and away from scanning the blockchain, is to be determined. Ideally we can go full p2p and can abstract wallet restoration support so it looks like it still works as it currently does

Okay, I think currently we find the transactions in an account by mapping transaction deltas to keyinstances to accounts. If we are going to index transactions that conflict, we do not want to apply them to the "account ledger" but we still want them associated with the account, so let's say we add a Transactions table flag of FLAG_CONFLICTING and everything that reads "account ledger" state should filter these out

Then we can have TransactionOutputs entries for them, and TransactionOutputSpends (TransactionInputs?) entries for them.

-- rt12

powered by powpress
link Tip
Share
tx
translate