📅 Original date posted:2011-10-24
🗒️ Summary of this message: Gavin Andresen suggests a potential issue with the "listtransactions" feature and proposes a solution to avoid performance penalties for users.
📝 Original message:On Mon, Oct 24, 2011 at 8:55 AM, Gavin Andresen <gavinandresen at gmail.com>wrote:
> If you assume the client has all previous transactions, then you could
> get the transaction input's prevout (from the memory pool or disk) and
> then ExtractAddress() from it. That is probably a bad idea for
> listtransactions, since fetching all the previous inputs from disk
> just so you can check to see if they're 'green' violates the "a
> feature shouldn't cost anything if it is not being used" design
> principle.
>
Are there current users of gettransaction for whom the performance penalty
would be problematic? If so, perhaps gettransaction could take an optional
second argument includeinputaddresses which defaults to false.
--
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111024/376c13b2/attachment.html>;
Michael Hendricks [ARCHIVE] /
npub1xs…c4k9q
2023-06-07 02:35:01
in reply to nevent1q…xxva
Author Public Key
npub1xs2ujdur5f653rjudvugjgtsaths04mpgl86rtcnrw24w7us8hmszc4k9qSeen on
wss://relay.nostr.bandPublished at
2023-06-07 02:35:01Event JSON
{
"id": "060ed1cbb19d3f9a785e546ce9060f3a3143111b92e9878fa7720025780a7fae",
"pubkey": "3415c93783a275488e5c6b38892170eaef07d76147cfa1af131b95577b903df7",
"created_at": 1686105301,
"kind": 1,
"tags": [
[
"e",
"30f32a4839f3515f22b5206d3110e202b851ce295fc65c5314c19fc43658750b",
"",
"root"
],
[
"e",
"7afeab3743827808547079fff6a1ed7527087efb061f8f08728883f6412a8023",
"",
"reply"
],
[
"p",
"e547cb012079af459e6ef2d5ab211d25de2dc9de0535f0d861d31cfc41cb04ff"
]
],
"content": "📅 Original date posted:2011-10-24\n🗒️ Summary of this message: Gavin Andresen suggests a potential issue with the \"listtransactions\" feature and proposes a solution to avoid performance penalties for users.\n📝 Original message:On Mon, Oct 24, 2011 at 8:55 AM, Gavin Andresen \u003cgavinandresen at gmail.com\u003ewrote:\n\n\u003e If you assume the client has all previous transactions, then you could\n\u003e get the transaction input's prevout (from the memory pool or disk) and\n\u003e then ExtractAddress() from it. That is probably a bad idea for\n\u003e listtransactions, since fetching all the previous inputs from disk\n\u003e just so you can check to see if they're 'green' violates the \"a\n\u003e feature shouldn't cost anything if it is not being used\" design\n\u003e principle.\n\u003e\n\nAre there current users of gettransaction for whom the performance penalty\nwould be problematic? If so, perhaps gettransaction could take an optional\nsecond argument includeinputaddresses which defaults to false.\n\n-- \nMichael\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111024/376c13b2/attachment.html\u003e",
"sig": "8587d51cd0e6bc8d38e5c85c4efe12a0b4c5e7468bedb0ec3d313318ac3dc72e83a90a144474d72f60f0a61fde32c1274e9f4b3be8966764931150265c134d19"
}