Using pubkeys as transaction inputs

[ondrere]

Now every input contains previous transaction hash and output index. Instead, we could just replace it by public key in compressed form. The meaning would be "take every previous output matching this key as an input in this transaction". It can be especially useful if there are many outputs with small amounts sent to some address.

[gmaxwell]

And then, after you've paid someone and you've received more funds, they can just resend your prior transaction to the network again to take those funds too.

[RHavar]

@ondrere sounds like your describing an "account system" (in contrast to a utxo system) which is what some currencies like ethereum use. It has some pretty big pros and cons, that have been discussed a lot.

And then, after you've paid someone and you've received more funds, they can just resend your prior transaction to the network again to take those funds too.

I think there's an easy fix, that I haven't seen anyone do. Do you see the problem with it?

Nodes maintain a set of spent txids, and thus refuse to accept the same transaction twice. This "spent txid" set would also be prunable, because each transaction would contain a "max block height" (thus the transaction itself expires). So you only need to keep the "spent txid" until it's unspendable anyway.

[gmaxwell]

Nodes maintain a set of spent txids, and thus refuse to accept the same transaction twice. This "spent txid" set would also be prunable, because each transaction would contain a "max block height" (thus the transaction itself expires). So you only need to keep the "spent txid" until it's unspendable anyway.

Max height is not reorg-safe. Spent txid is vulnerable to malleation unless lots of limitations are imposed to make it not.

Also makes it hard or impossible to create intentional conflicts:  E.g. I pay alice txn A.. But later want to change my fees so I author txn B.  I want to be sure that only one can confirm.

Instead of txid, you can have just a spender created nonce. Avoids the malleation, lets you direct a conflict. But at that point I think you've just recreated what bitcoin does but less efficient. (on the plus side, if the nonce isn't grouped per-key, you can do some rather elaborate tricks with mutually exclusive sets of transactions which you could only do in bitcoin by creating a bunch of 0-value semaphore outputs).

[RHavar]

Max height is not reorg-safe.

I don't see how that matters -- the consensus rule would be "the same txid can't ever be included twice" and "a transaction can't ever be included in a block greater than its max-height". And nodes use the "max-height" to determine when they think is safe to prune (but there is no obligation to do so) but they can be stupidly conservative (e.g. only prune week old stuff). This is pretty much the same in bitcoin, where pruning isn't "re-org safe" but in practice it doesn't matter

Spent txid is vulnerable to malleation unless lots of limitations are imposed to make it not.

Don't really know anything about this, but I wouldn't have thought it's a big deal.

Also makes it hard or impossible to create intentional conflicts:  E.g. I pay alice txn A.. But later want to change my fees so I author txn B.  I want to be sure that only one can confirm.

Agree this kind of sucks.

Instead of txid, you can have just a spender created nonce. Avoids the malleation, lets you direct a conflict. But at that point I think you've just recreated what bitcoin does but less efficient. (on the plus side, if the nonce isn't grouped per-key, you can do some rather elaborate tricks with mutually exclusive sets of transactions which you could only do in bitcoin by creating a bunch of 0-value semaphore outputs).

Yeah, there's some nice properties of a nonce, but I don't really get how you can prune efficiently which seems suboptimal. I'm kind of in the camp that running a non-pruned node is massive overkill, and the IBD is nuts and safe people aren't going to go through it. So I kind of like the "account system" style as they seem to naturally support light-clients a lot better. Although I can't say it's something I care that much or think very much about

[gmaxwell]

So I kind of like the "account system" style as they seem to naturally support light-clients a lot better. Although I can't say it's something I care that much or think very much about

Yeah, if you think more I think you'll realize you're mistaken.  Anything an account system would have is there in the utxo set.  The utxo set doesn't have a history, but an account 'balance' doesn't either.  Efficiency differences from there are just a matter of having zero privacy is more efficient, so if you implement 'single account per user' -- it's more efficient too look up, but utterly murderous for privacy (sometimes literally?). Of course, UTXO looking up via an untrusted host isn't so efficient without a commitment to a utxo set, but that's not an account vs not account question.

[RHavar]

Yeah, if you think more I think you'll realize you're mistaken.  Anything an account system would have is there in the utxo set.  The utxo set doesn't have a history, but an account 'balance' doesn't either.  Efficiency differences from there are just a matter of having zero privacy is more efficient, so if you implement 'single account per user' -- it's more efficient too look up, but utterly murderous for privacy (sometimes literally?). Of course, UTXO looking up via an untrusted host isn't so efficient without a commitment to a utxo set, but that's not an account vs not account question.

I was thinking even with an account system, you'd still generally want to use it like bitcoin (e.g. a transaction could have multiple outputs, and you try not to reuse accounts). I guess major property I like of account based systems is say you have a sync'd node, you can naturally very easily import private keys without a rescan. While I guess it's never an "essential" operation, in practice I think it's very very very useful. Even if bitcoin gets a utxo set commitment (Which I think it could very much benefit from), you'd still never realistically see a "address index commitment" or the sorts.

[gmaxwell]

I guess major property I like of account based systems is say you have a sync'd node, you can naturally very easily import private keys without a rescan.

Thats not really a property of 'accounts' though.  See also: scantxoutset RPC.

[RHavar]

Thats not really a property of 'accounts' though.  See also: scantxoutset RPC.

Sure, I get that. But in practice is sort of is.


I guess you could build some sort of "multi_index" for the txoutset, which allows lookup via (txid), but also via (script).  Then merkelize that shit, and make it part of the block commitment.


Now that would be bad-ass. But I have a feeling we'll never see that . While you sort of more or less get that out-of-the-box with something like ethereum (although you obviously get a ton of disadvantages from their account system too)