📅 Original date posted:2019-07-29
📝 Original message:Good morning Mike,
> > The problem with transaction being pruned is that the data in them might now be used in a *future* `OP_PUBREF`.
>
> I can see how pruning is needed for scalability, and pruning can be made compatible with a reference to a transaction. If a transaction is pruned, then the key material used in a prune'ed block's PUSHDATA operations are of no value. A user of the network shouldn't need to make this kind of PUBREF, and if a user did want to bring a wallet back from the dead - then the utility of PUBREF wouldn't be available to them.
I believe you misunderstand the point completely.
Currently Bitcoin Core has a mode, called pruning, where:
1. It validates ***all*** transactions.
2. It throws away the transaction data of a block ***after*** validation.
3. It keeps only the UTXO set of ***all*** addresses, not just a specific wallet.
Given the above, if a transaction block 1000 `OP_PUBREF`s to a `OP_PUSHDATA` in block 100, how does the pruned validator get access to this data (Which was pruned after the pruned validator handled block 100)?
Note that pruned nodes ***are*** fullnodes and validate all transactions, not just those that involve their wallet.
Regards,
ZmnSCPxj
ZmnSCPxj [ARCHIVE] /
npub1g5…3ms3l
2023-06-07 18:19:32
in reply to nevent1q…22p7
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lPublished at
2023-06-07 18:19:32Event JSON
{
"id": "4b7fabde8e3f2835760d6191c8d17634c3ce33897c7125c3a78e5d0842ad7b77",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686161972,
"kind": 1,
"tags": [
[
"e",
"2be9b6a431947a4225725c7aed41a672659fa904edbb4c85a3e34f0d68e8d93d",
"",
"root"
],
[
"e",
"c70bf14c82b07f9c525c212ef5f6b3376ea7c3b687b24deeef14ebdc3b18f939",
"",
"reply"
],
[
"p",
"2b3ecf9385e6a66ed65ff0457b4a59163fabb80075bc34638fb1d55497cc4a55"
]
],
"content": "📅 Original date posted:2019-07-29\n📝 Original message:Good morning Mike,\n\n\u003e \u003e The problem with transaction being pruned is that the data in them might now be used in a *future* `OP_PUBREF`.\n\u003e\n\u003e I can see how pruning is needed for scalability, and pruning can be made compatible with a reference to a transaction. If a transaction is pruned, then the key material used in a prune'ed block's PUSHDATA operations are of no value. A user of the network shouldn't need to make this kind of PUBREF, and if a user did want to bring a wallet back from the dead - then the utility of PUBREF wouldn't be available to them.\n\nI believe you misunderstand the point completely.\n\nCurrently Bitcoin Core has a mode, called pruning, where:\n\n1. It validates ***all*** transactions.\n2. It throws away the transaction data of a block ***after*** validation.\n3. It keeps only the UTXO set of ***all*** addresses, not just a specific wallet.\n\nGiven the above, if a transaction block 1000 `OP_PUBREF`s to a `OP_PUSHDATA` in block 100, how does the pruned validator get access to this data (Which was pruned after the pruned validator handled block 100)?\n\nNote that pruned nodes ***are*** fullnodes and validate all transactions, not just those that involve their wallet.\n\nRegards,\nZmnSCPxj",
"sig": "4fdc964022d7afa182fb0ff1b9aa4e7a9092fbf3cc241e8d935e57f215dd94960734c83c5a3455c9095444f2ee7dcaca5485785361821260c08530abd95faae4"
}