📅 Original date posted:2011-10-24
🗒️ Summary of this message: Jan is trying to add an "inputaddresses" field to the "gettransaction" call in Bitcoin, but is unsure if his method is safe and seeks advice.
📝 Original message:Hi there!
As part of my green address endeavor, I'm currently trying to extend the
'gettransaction' call to include an extra field "inputaddresses" which
should return a list of the Bitcoin addresses associated with the inputs
of the transaction.
I understand that this is not generally possible, because of the different
possible structures enabled through the scripting language. But it would
be fine, if this only worked for 'regular' transactions.
So my first shot at this is to go through the inputs of a transaction and
see if the scriptSig field has only two opcodes. If that is the case, I
assume that it is of the structure <sig> <pubKey> and calculate the
Bitcoin address from <pubKey>. The patch for this is here:
https://github.com/javgh/bitcoin/compare/vps_wheezy...showinputaddresses
But then I started to wonder if this is safe. Can this be tricked somehow?
Would it be possible to create a valid transaction which has an input that
has only two opcodes but with an arbitrary pubKey at the second position?
Could someone who has a better grasp on the scripting capabilities comment
on this?
Or alternatively: should I determine the input addresses of a transaction
in a different way? if so, how?
Regards!
Jan
Jan Vornberger [ARCHIVE] /
npub147…tnsv4
2023-06-07 02:34:42
in reply to nevent1q…rtm8
Author Public Key
npub147edljttlezv8m5dugzg4ka8cg3073j3t2hq4h8ncxaz9sm5swuq4tnsv4Published at
2023-06-07 02:34:42Event JSON
{
"id": "10511d84cd407e24803db2dde64d77aedd9207be75188716e3db3342da35a63d",
"pubkey": "afb2dfc96bfe44c3ee8de2048adba7c222ff46515aae0adcf3c1ba22c37483b8",
"created_at": 1686105282,
"kind": 1,
"tags": [
[
"e",
"30f32a4839f3515f22b5206d3110e202b851ce295fc65c5314c19fc43658750b",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2011-10-24\n🗒️ Summary of this message: Jan is trying to add an \"inputaddresses\" field to the \"gettransaction\" call in Bitcoin, but is unsure if his method is safe and seeks advice.\n📝 Original message:Hi there!\n\nAs part of my green address endeavor, I'm currently trying to extend the\n'gettransaction' call to include an extra field \"inputaddresses\" which\nshould return a list of the Bitcoin addresses associated with the inputs\nof the transaction.\n\nI understand that this is not generally possible, because of the different\npossible structures enabled through the scripting language. But it would\nbe fine, if this only worked for 'regular' transactions.\n\nSo my first shot at this is to go through the inputs of a transaction and\nsee if the scriptSig field has only two opcodes. If that is the case, I\nassume that it is of the structure \u003csig\u003e \u003cpubKey\u003e and calculate the\nBitcoin address from \u003cpubKey\u003e. The patch for this is here:\n\nhttps://github.com/javgh/bitcoin/compare/vps_wheezy...showinputaddresses\n\nBut then I started to wonder if this is safe. Can this be tricked somehow?\nWould it be possible to create a valid transaction which has an input that\nhas only two opcodes but with an arbitrary pubKey at the second position?\nCould someone who has a better grasp on the scripting capabilities comment\non this?\n\nOr alternatively: should I determine the input addresses of a transaction\nin a different way? if so, how?\n\nRegards!\nJan",
"sig": "fe02afbb403a7f2c2506c366e472cbbecc50b5519df572231c14d6563403acb5bebfc1e1cd9548cf0ce26c27104f5c88e2d12e469c2726ed07379432e14ecc8b"
}