3 ms·

Fun fact: Ethereum transaction does not include sender's address or pubkey. It is calculated from the signature. I'm not sure if Bitcoin can use this trick, a

Fun fact: Ethereum transaction does not include sender's address or pubkey. It is calculated from the signature. I'm not sure if Bitcoin can use this trick, at least the classic transaction types explicitly included pubkey.

westurner 2y ago
The pubkey is shared once any transaction transfers out of an account. There are now hierarchical wallet keys. Which systems asymmetrically cryptographically transact without de-blinding the pubkey, without hiding more than the signature?
csomar 2y ago
There is no sender in Bitcoin. You consume outputs. There is also no "Public Key", you just need to satisfy the condition of the output script. Quite a different architecture from Ethereum where you have an actual account.
- treyd 2y ago
  There is pubkeys but they're embedded in a script which is defined by the address format. There's almost no outputs that don't contain a pubkey since scripts that don't commit to a spend with a signature could just be spent by anyone paying attention and consumed.
  - csomar 2y ago
    > by the address format This is not a requirement. You can have outputs that have no "address". They are just hanging there. The risk for non-pubkey signed messages is that once you broadcast your script, anyone else can consume your outputs.
    - treyd 2y ago
      Right but this is very much a special case that doesn't satisfy the tx standardness rules so it'd require more effort to include in a block.
- killerstorm 2y ago
  Almost all Bitcoin transaction include at least one public key. It is a part of a script.
  - lxgr 2y ago
    If that's the case, that's most likely out of efficiency or other considerations; ECDSA definitely allows the recovery of the public key from message and signature alone.
  - csomar 2y ago
    Almost # All. Sure, 99% of transactions work that way but it is not a requirement.
    - lxgr 2y ago
      That's not the point here, though: Most transactions do indeed use an ECDSA signature; the question is whether the signature format used by these transactions explicitly includes the public key as well, or whether it's implied and recovered from message and signature, as is possible with ECDSA.
- lxgr 2y ago
  Technically you're right (Bitcoin's UTXO and script model implements a general and quite flexible mechanism); practically, almost all transactions use that mechanism to implement the regular old "account a (a set of public/private keypairs) transfers money to account b (holder(s) of other keypairs)" model.
nullc 2y ago
Recovery for ECDSA is a well known technique but it makes verification much slower and makes batch verification impossible. It also doesn't really result in a size reduction in most cases where a key must already be communicated somehow. It also depends on the message hash not depending on the public key, which prevents the signature from being a proof of knowledge of the private key (you can just pick a random message and random signature and it will be valid for some random pubkey which you don't know the private key for)... this can result in security vulnerabilities though the requirements for it to do so are a bit contrived (but I seem to recall finding some examples previously). Implementations also potentially infringe a specific known patent -- one that appears to have just been transferred to a patent troll. So recovery users, hold on to your pants!
- lxgr 2y ago
  Interesting, hasn't ECDSA been around way too long for possible patents to still be a concern (due to either being expired or prior art long predating their filing date)?
  - nullc 2y ago
    It's specific to ECDSA recovery, where instead of using a pubkey and message to validate a signature you use a signature and message to recover the pubkey, so the age of ECDSA isn't particularly relevant in and of itself.
    - lxgr 2y ago
      Huh, interesting! I somehow assumed that that fact would be obvious enough to implementers for there to be prior art. Do you have any more details?
      - nullc 2y ago
        > obvious enough to implementers for there to be prior art. Do you have any more details? I haven't made any comment in this thread on its validity. :) US8788 827B2
lxgr 2y ago
As far as I know Bitcoin does this too, yes (or at least it could; I've seen some conflicting information). It's a property of ECDSA signatures, not anything blockchain specific.

westurner 2y ago

The pubkey is shared once any transaction transfers out of an account. There are now hierarchical wallet keys. Which systems asymmetrically cryptographically transact without de-blinding the pubkey, without hiding more than the signature?

csomar 2y ago

There is no sender in Bitcoin. You consume outputs. There is also no "Public Key", you just need to satisfy the condition of the output script. Quite a different architecture from Ethereum where you have an actual account.

treyd 2y ago
There is pubkeys but they're embedded in a script which is defined by the address format. There's almost no outputs that don't contain a pubkey since scripts that don't commit to a spend with a signature could just be spent by anyone paying attention and consumed.
- csomar 2y ago
  > by the address format This is not a requirement. You can have outputs that have no "address". They are just hanging there. The risk for non-pubkey signed messages is that once you broadcast your script, anyone else can consume your outputs.
  - treyd 2y ago
    Right but this is very much a special case that doesn't satisfy the tx standardness rules so it'd require more effort to include in a block.
killerstorm 2y ago
Almost all Bitcoin transaction include at least one public key. It is a part of a script.
- lxgr 2y ago
  If that's the case, that's most likely out of efficiency or other considerations; ECDSA definitely allows the recovery of the public key from message and signature alone.
- csomar 2y ago
  Almost # All. Sure, 99% of transactions work that way but it is not a requirement.
  - lxgr 2y ago
    That's not the point here, though: Most transactions do indeed use an ECDSA signature; the question is whether the signature format used by these transactions explicitly includes the public key as well, or whether it's implied and recovered from message and signature, as is possible with ECDSA.
lxgr 2y ago
Technically you're right (Bitcoin's UTXO and script model implements a general and quite flexible mechanism); practically, almost all transactions use that mechanism to implement the regular old "account a (a set of public/private keypairs) transfers money to account b (holder(s) of other keypairs)" model.

nullc 2y ago

Recovery for ECDSA is a well known technique but it makes verification much slower and makes batch verification impossible. It also doesn't really result in a size reduction in most cases where a key must already be communicated somehow. It also depends on the message hash not depending on the public key, which prevents the signature from being a proof of knowledge of the private key (you can just pick a random message and random signature and it will be valid for some random pubkey which you don't know the private key for)... this can result in security vulnerabilities though the requirements for it to do so are a bit contrived (but I seem to recall finding some examples previously). Implementations also potentially infringe a specific known patent -- one that appears to have just been transferred to a patent troll. So recovery users, hold on to your pants!

lxgr 2y ago
Interesting, hasn't ECDSA been around way too long for possible patents to still be a concern (due to either being expired or prior art long predating their filing date)?
- nullc 2y ago
  It's specific to ECDSA recovery, where instead of using a pubkey and message to validate a signature you use a signature and message to recover the pubkey, so the age of ECDSA isn't particularly relevant in and of itself.
  - lxgr 2y ago
    Huh, interesting! I somehow assumed that that fact would be obvious enough to implementers for there to be prior art. Do you have any more details?
    - nullc 2y ago
      > obvious enough to implementers for there to be prior art. Do you have any more details? I haven't made any comment in this thread on its validity. :) US8788 827B2

lxgr 2y ago

As far as I know Bitcoin does this too, yes (or at least it could; I've seen some conflicting information). It's a property of ECDSA signatures, not anything blockchain specific.