Bitcoin Forum
March 29, 2024, 05:28:23 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Using pubkeys as transaction inputs  (Read 206 times)
ondrere (OP)
Newbie
*
Offline Offline

Activity: 3
Merit: 2


View Profile
May 06, 2020, 05:01:07 PM
 #1

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.
1711690103
Hero Member
*
Offline Offline

Posts: 1711690103

View Profile Personal Message (Offline)

Ignore
1711690103
Reply with quote  #2

1711690103
Report to moderator
1711690103
Hero Member
*
Offline Offline

Posts: 1711690103

View Profile Personal Message (Offline)

Ignore
1711690103
Reply with quote  #2

1711690103
Report to moderator
1711690103
Hero Member
*
Offline Offline

Posts: 1711690103

View Profile Personal Message (Offline)

Ignore
1711690103
Reply with quote  #2

1711690103
Report to moderator
The trust scores you see are subjective; they will change depending on who you have in your trust list.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1711690103
Hero Member
*
Offline Offline

Posts: 1711690103

View Profile Personal Message (Offline)

Ignore
1711690103
Reply with quote  #2

1711690103
Report to moderator
1711690103
Hero Member
*
Offline Offline

Posts: 1711690103

View Profile Personal Message (Offline)

Ignore
1711690103
Reply with quote  #2

1711690103
Report to moderator
1711690103
Hero Member
*
Offline Offline

Posts: 1711690103

View Profile Personal Message (Offline)

Ignore
1711690103
Reply with quote  #2

1711690103
Report to moderator
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4158
Merit: 8343



View Profile WWW
May 06, 2020, 05:20:35 PM
Merited by Foxpup (2), ABCbits (1)
 #2

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
Legendary
*
Offline Offline

Activity: 2555
Merit: 1886



View Profile
May 06, 2020, 06:39:53 PM
 #3

@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.

Check out gamblingsitefinder.com for a decent list/rankings of crypto casinos. Note: I have no affiliation or interest in it, and don't even agree with all the rankings ... but it's the only uncorrupted review site I'm aware of.
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4158
Merit: 8343



View Profile WWW
May 07, 2020, 12:08:12 AM
 #4

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
Legendary
*
Offline Offline

Activity: 2555
Merit: 1886



View Profile
May 07, 2020, 06:52:47 AM
 #5

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

Quote
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.

Quote
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.


Quote
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 Cheesy

Check out gamblingsitefinder.com for a decent list/rankings of crypto casinos. Note: I have no affiliation or interest in it, and don't even agree with all the rankings ... but it's the only uncorrupted review site I'm aware of.
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4158
Merit: 8343



View Profile WWW
May 07, 2020, 09:23:32 AM
 #6

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 Cheesy
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
Legendary
*
Offline Offline

Activity: 2555
Merit: 1886



View Profile
May 07, 2020, 03:28:02 PM
 #7

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.

Check out gamblingsitefinder.com for a decent list/rankings of crypto casinos. Note: I have no affiliation or interest in it, and don't even agree with all the rankings ... but it's the only uncorrupted review site I'm aware of.
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4158
Merit: 8343



View Profile WWW
May 07, 2020, 04:11:38 PM
 #8

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
Legendary
*
Offline Offline

Activity: 2555
Merit: 1886



View Profile
May 07, 2020, 05:22:07 PM
 #9

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 Cheesy. 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)

Check out gamblingsitefinder.com for a decent list/rankings of crypto casinos. Note: I have no affiliation or interest in it, and don't even agree with all the rankings ... but it's the only uncorrupted review site I'm aware of.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!