📅 Original date posted:2020-06-09
📝 Original message:Hello,
Just a few comments.
>But there is no guarantee that ndes should keep all of them from the
genesis. It depends. Maybe some nodes want to keep all the transactions,
some part of them and might nothing.
There is no guarantee that nodes keep them all from the genesis now, nodes
can turn on pruning if the operator doesn't desire to keep all the
transactions from the genesis block
(https://github.com/bitcoin/bitcoin/blob/v0.11.0/doc/release-notes.md#block-file-pruning).
Likewise, light clients may not keep any transaction history.
>Also we can think about check pointing. When a new node connects to the
network, it doesn't need to validate all the blocks since genesis. It can
start validating from a checkpoint.
>Transactions have their own way to survive. Owner of the coin can keep the
history of his transactions.
There have been some checkpoint discussions on here too, which have
discussed the pros and cons of them.
see, e.g.:
site:https://lists.linuxfoundation.org/pipermail/bitcoin-dev/ checkpointand:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/016001.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017209.html
Without introducing trusted people, how can you prove that the "owner" is
person A or B without verification from the genesis block? For example, A
or B could claim to be the owner and provide an altered client with an
altered checkpoint to "prove" it.
>Anytime the bitcoin community decides to make a hard-fork, you might
consider this change as well
>From reading the initial bitcoin paper, many proposals etc since and having
been around the "bitcoin community" for 9 years, I think that this change
has a very, very small chance of ever happening because full transaction
verification is an important part of the blockchain bank. Not to say this
isn't a useful, interesting, informative, and educational discussion, but
it seems unlikely to happen. Likewise, it could lead to something related
that would be likely to occur, so full discussions like this are useful.
Regards, :-)
Chris
On Tue, Jun 9, 2020 at 7:20 AM Mostafa Sedaghat joo via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Good day ZmnSCPxj
>
> As I said before, I don't expect a hard fork for this change. I wanted to
> share my thoughts with you guys. Anytime the bitcoin community decides to
> make a hard-fork, you might consider this change as well.
> I believe decoupling transactions from the block is beautiful.
>
> About transaction verification,
> Transactions have their own way to survive. Owner of the coin can keep the
> history of his transactions.
> But there is no guarantee that ndes should keep all of them from the
> genesis. It depends. Maybe some nodes want to keep all the transactions,
> some part of them and might nothing.
> Also we can think about check pointing. When a new node connects to the
> network, it doesn't need to validate all the blocks since genesis. It can
> start validating from a checkpoint.
>
> And also adding 32 bits to the header of translation (which won't be saved
> inside the block) is not a big deal.
>
>
> Adios,
> Mostafa
>
>
>
> On Sun, Jun 7, 2020 at 11:01 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
>> Good morning Mostafa,
>>
>>
>> > The main point of stamping transactions is decoupling transactions from
>> the block.
>> >
>> > Blockchain size matters
>> > SegWit is a good witness that shows blockchain size matters.
>> Nowadays, Data storage is cheap and easy, but that doesn't mean it's a
>> simple matter. If you need to have a data-center to keep a copy of a
>> blockchain, then you are far from a decentralization system.
>> >
>> > A Solution
>> > Stamping transaction is a simple idea to keep the size of the
>> blockchain as small as possible. The question that I was looking to answer
>> is how we can decouple the transaction from the blocks.
>> > Who cares about the transaction that happened 10 years ago. In the real
>> world you may go to your bank and ask them to give you transaction history.
>> But they probably have limits. They might say we just only keep the last 3
>> months in our system.
>>
>> Stamping transaction is not how you would be able to keep **blockchain**
>> size low.
>>
>> The reason why very old history is retained is that, if a new node is
>> brought up, you need to prove to that node that you are in fact the correct
>> owner of the current coins.
>> Thus the entire history of Bitcoin is needed when starting a new node,
>> and why archive nodes exist.
>>
>> You might argue that banks do not do that, and that is because we want to
>> do better than banks; we know that existing currency systems have not only
>> the "official" minter, but also many "unofficial" minters (commonly called
>> counterfeiters) which dilute the value of the currency.
>> It is this insistence on a full accounting of the provenance for every
>> satoshi that separates Bitcoin from previous currency systems; bank fraud
>> exists, and it hides in such sloppy techniques as deleting old transaction
>> records.
>>
>> Work has been done to have client-side validation (i.e. the owner of a
>> coin keeps the entire history, and when paying, you hand over the entire
>> history of your coin to the payee, instead of everyone validating every
>> transaction).
>> Look up Peter Todd for some initial work on this.
>>
>>
>> > Implementation
>> >
>> > > First off, the proposed mechanism can be made into a softfork by
>> using an unspendable `scriptPubKey` with 0 output value.
>> > SoftFork is not possible here. Because the transaction will not be
>> saved inside the block (only tx hashes). Block format needs to be changed.
>> Therefore the block will be invalid.
>>
>> That greatly reduces the chances your proposal will get into Bitcoin; you
>> would need to have very good advantages to counterbalance the tremendous
>> risk that hardforks introduce in the continuity of the coin.
>>
>> Bitcoin has never gone through a hardfork that has not instead created a
>> new cryptocurrency, so any solution that requires a hardfork is going to be
>> unlikely to be accepted by everyone.
>>
>> > > Engineering-wise, block validation now needs to memorize the last N
>> block hashes.
>> > I don't think we need to memorize the last N block hashes. We can have
>> something like:
>> > ```
>> > Current_Height - Height_Of(tx.stamp) <= N
>> > ```
>>
>> ...
>>
>>
>> `Height_Of()` would basically be a mapping from block hashes to block
>> heights, with the number of elements equal to the height of the blockchain,
>> and thus continuously growing.
>> Thus, validation is expected to become more expensive as the blockchain
>> grows.
>>
>> Since stamped transactions have a time-to-live anyway, instead you can
>> use a *set* of the most recent N block hashes.
>> Then you simply check if the stamp is in the set.
>> This creates a data structure that is constant in size (at each block,
>> you remove the block from N blocks ago), which is good for validation.
>>
>> > Incentives
>> > I think Stamping transactions have nothing to do with the
>> incentivization mechanism. Forgive me if I couldn't get your point.
>>
>> A stamped tranasction has a stamp, an unstamped transaction has no stamp.
>> The stamped transaction is larger because of the stamp.
>> Larger transactions are more expensive because fees.
>>
>> Thus, stamped transactions are more expensive than unstamped transactions.
>>
>> Convince me why I would make *my* transaction stamped when I can just
>> convince *everyone else* to stamp *their* transactions and use unstamped
>> transactions myself.
>>
>> If you propose that all transactions must be stamped in a new version of
>> Bitcoin, then take note that users will prefer to run older versions and
>> never upgrade to the new version that requires stamped transactions.
>> Why should users prefer a more expensive transaction format?
>> For the good of the network?
>> That is precisely an incentives problem: if it is so good for the
>> network, then it should be good for an individual user, because the network
>> is made up of individual users anyway; if individual users are not
>> incentivized to use it, then that fact suggests it might not be as good for
>> the network as you might think.
>>
>> If you answer "the stamp can be discounted" then be aware that validating
>> the stamp is still a cost on every node, and it is that cost that we want
>> to be reflected in pricing every byte in the transaction.
>> For instance, UTXOs are retained, potentially indefinitely, and the UTXO
>> lookup structure has to be very fast and is referred to at every
>> transaction validation, so outputs (which create new UTXO entries) in
>> SegWit are 4x more expensive than signatures, since signatures are only
>> validated once when the transaction is queued to be put in the mempool.
>>
>>
>> > Mempool
>> > It's bad of me that I don't really know how mempool works in Bitcoin.
>> My assumption is that there are some junk transactions (transactions that
>> are valid but have very low or zero fees) inside the mempool. Stamping
>> transactions might help to get rid of them time to time.
>>
>> Why would you think that stamping reduces mempool size?
>>
>> If I wanted to I could just re-send the transaction with a fresh stamp.
>> Then the mempool usage would still be the same, and bandwidth use will
>> increase (because the same transaction is now re-broadcast with a fresh
>> stamp, and the added size of the stamps themselves).
>>
>>
>> Regards,
>> ZmnSCPxj
>>
>> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200609/158605a4/attachment.html>;
Chris Riley [ARCHIVE] /
npub128…45an7
2023-06-07 18:25:16
in reply to nevent1q…apy8
Author Public Key
npub1287e20y3ple0k202xuas3h9h0yfx6ravfxcycd9jauan8cne9pusj45an7Seen on
wss://relay.nostr.bandPublished at
2023-06-07 18:25:16Event JSON
{
"id": "29a28dc2313575859d69f3eb62d7728a779510b8af3f221caf82608ec66efe2f",
"pubkey": "51fd953c910ff2fb29ea373b08dcb779126d0fac49b04c34b2ef3b33e2792879",
"created_at": 1686162316,
"kind": 1,
"tags": [
[
"e",
"aa726fb680863356730366de4f0c02ee2cdeb174c06f5887aee647b154b63d99",
"",
"root"
],
[
"e",
"645c8f4dd8eca55976305e495943941923097667d7ae293d38cdfeac509493bd",
"",
"reply"
],
[
"p",
"1de04532048d9d0da5a74edfa3d50d478abb513af7b7686e251ca004db68359d"
]
],
"content": "📅 Original date posted:2020-06-09\n📝 Original message:Hello,\n\nJust a few comments.\n\n\u003eBut there is no guarantee that ndes should keep all of them from the\ngenesis. It depends. Maybe some nodes want to keep all the transactions,\nsome part of them and might nothing.\nThere is no guarantee that nodes keep them all from the genesis now, nodes\ncan turn on pruning if the operator doesn't desire to keep all the\ntransactions from the genesis block\n(https://github.com/bitcoin/bitcoin/blob/v0.11.0/doc/release-notes.md#block-file-pruning).\nLikewise, light clients may not keep any transaction history.\n\n\u003eAlso we can think about check pointing. When a new node connects to the\nnetwork, it doesn't need to validate all the blocks since genesis. It can\nstart validating from a checkpoint.\n\u003eTransactions have their own way to survive. Owner of the coin can keep the\nhistory of his transactions.\nThere have been some checkpoint discussions on here too, which have\ndiscussed the pros and cons of them.\nsee, e.g.:\nsite:https://lists.linuxfoundation.org/pipermail/bitcoin-dev/ checkpointand:\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/016001.html\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017209.html\n\nWithout introducing trusted people, how can you prove that the \"owner\" is\nperson A or B without verification from the genesis block? For example, A\nor B could claim to be the owner and provide an altered client with an\naltered checkpoint to \"prove\" it.\n\n\u003eAnytime the bitcoin community decides to make a hard-fork, you might\nconsider this change as well\n\u003eFrom reading the initial bitcoin paper, many proposals etc since and having\nbeen around the \"bitcoin community\" for 9 years, I think that this change\nhas a very, very small chance of ever happening because full transaction\nverification is an important part of the blockchain bank. Not to say this\nisn't a useful, interesting, informative, and educational discussion, but\nit seems unlikely to happen. Likewise, it could lead to something related\nthat would be likely to occur, so full discussions like this are useful.\n\nRegards, :-)\nChris\n\nOn Tue, Jun 9, 2020 at 7:20 AM Mostafa Sedaghat joo via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Good day ZmnSCPxj\n\u003e\n\u003e As I said before, I don't expect a hard fork for this change. I wanted to\n\u003e share my thoughts with you guys. Anytime the bitcoin community decides to\n\u003e make a hard-fork, you might consider this change as well.\n\u003e I believe decoupling transactions from the block is beautiful.\n\u003e\n\u003e About transaction verification,\n\u003e Transactions have their own way to survive. Owner of the coin can keep the\n\u003e history of his transactions.\n\u003e But there is no guarantee that ndes should keep all of them from the\n\u003e genesis. It depends. Maybe some nodes want to keep all the transactions,\n\u003e some part of them and might nothing.\n\u003e Also we can think about check pointing. When a new node connects to the\n\u003e network, it doesn't need to validate all the blocks since genesis. It can\n\u003e start validating from a checkpoint.\n\u003e\n\u003e And also adding 32 bits to the header of translation (which won't be saved\n\u003e inside the block) is not a big deal.\n\u003e\n\u003e\n\u003e Adios,\n\u003e Mostafa\n\u003e\n\u003e\n\u003e\n\u003e On Sun, Jun 7, 2020 at 11:01 PM ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e wrote:\n\u003e\n\u003e\u003e Good morning Mostafa,\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e \u003e The main point of stamping transactions is decoupling transactions from\n\u003e\u003e the block.\n\u003e\u003e \u003e\n\u003e\u003e \u003e Blockchain size matters\n\u003e\u003e \u003e SegWit is a good witness that shows blockchain size matters.\n\u003e\u003e Nowadays, Data storage is cheap and easy, but that doesn't mean it's a\n\u003e\u003e simple matter. If you need to have a data-center to keep a copy of a\n\u003e\u003e blockchain, then you are far from a decentralization system.\n\u003e\u003e \u003e\n\u003e\u003e \u003e A Solution\n\u003e\u003e \u003e Stamping transaction is a simple idea to keep the size of the\n\u003e\u003e blockchain as small as possible. The question that I was looking to answer\n\u003e\u003e is how we can decouple the transaction from the blocks.\n\u003e\u003e \u003e Who cares about the transaction that happened 10 years ago. In the real\n\u003e\u003e world you may go to your bank and ask them to give you transaction history.\n\u003e\u003e But they probably have limits. They might say we just only keep the last 3\n\u003e\u003e months in our system.\n\u003e\u003e\n\u003e\u003e Stamping transaction is not how you would be able to keep **blockchain**\n\u003e\u003e size low.\n\u003e\u003e\n\u003e\u003e The reason why very old history is retained is that, if a new node is\n\u003e\u003e brought up, you need to prove to that node that you are in fact the correct\n\u003e\u003e owner of the current coins.\n\u003e\u003e Thus the entire history of Bitcoin is needed when starting a new node,\n\u003e\u003e and why archive nodes exist.\n\u003e\u003e\n\u003e\u003e You might argue that banks do not do that, and that is because we want to\n\u003e\u003e do better than banks; we know that existing currency systems have not only\n\u003e\u003e the \"official\" minter, but also many \"unofficial\" minters (commonly called\n\u003e\u003e counterfeiters) which dilute the value of the currency.\n\u003e\u003e It is this insistence on a full accounting of the provenance for every\n\u003e\u003e satoshi that separates Bitcoin from previous currency systems; bank fraud\n\u003e\u003e exists, and it hides in such sloppy techniques as deleting old transaction\n\u003e\u003e records.\n\u003e\u003e\n\u003e\u003e Work has been done to have client-side validation (i.e. the owner of a\n\u003e\u003e coin keeps the entire history, and when paying, you hand over the entire\n\u003e\u003e history of your coin to the payee, instead of everyone validating every\n\u003e\u003e transaction).\n\u003e\u003e Look up Peter Todd for some initial work on this.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e \u003e Implementation\n\u003e\u003e \u003e\n\u003e\u003e \u003e \u003e First off, the proposed mechanism can be made into a softfork by\n\u003e\u003e using an unspendable `scriptPubKey` with 0 output value.\n\u003e\u003e \u003e SoftFork is not possible here. Because the transaction will not be\n\u003e\u003e saved inside the block (only tx hashes). Block format needs to be changed.\n\u003e\u003e Therefore the block will be invalid.\n\u003e\u003e\n\u003e\u003e That greatly reduces the chances your proposal will get into Bitcoin; you\n\u003e\u003e would need to have very good advantages to counterbalance the tremendous\n\u003e\u003e risk that hardforks introduce in the continuity of the coin.\n\u003e\u003e\n\u003e\u003e Bitcoin has never gone through a hardfork that has not instead created a\n\u003e\u003e new cryptocurrency, so any solution that requires a hardfork is going to be\n\u003e\u003e unlikely to be accepted by everyone.\n\u003e\u003e\n\u003e\u003e \u003e \u003e Engineering-wise, block validation now needs to memorize the last N\n\u003e\u003e block hashes.\n\u003e\u003e \u003e I don't think we need to memorize the last N block hashes. We can have\n\u003e\u003e something like:\n\u003e\u003e \u003e ```\n\u003e\u003e \u003e Current_Height - Height_Of(tx.stamp) \u003c= N\n\u003e\u003e \u003e ```\n\u003e\u003e\n\u003e\u003e ...\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e `Height_Of()` would basically be a mapping from block hashes to block\n\u003e\u003e heights, with the number of elements equal to the height of the blockchain,\n\u003e\u003e and thus continuously growing.\n\u003e\u003e Thus, validation is expected to become more expensive as the blockchain\n\u003e\u003e grows.\n\u003e\u003e\n\u003e\u003e Since stamped transactions have a time-to-live anyway, instead you can\n\u003e\u003e use a *set* of the most recent N block hashes.\n\u003e\u003e Then you simply check if the stamp is in the set.\n\u003e\u003e This creates a data structure that is constant in size (at each block,\n\u003e\u003e you remove the block from N blocks ago), which is good for validation.\n\u003e\u003e\n\u003e\u003e \u003e Incentives\n\u003e\u003e \u003e I think Stamping transactions have nothing to do with the\n\u003e\u003e incentivization mechanism. Forgive me if I couldn't get your point.\n\u003e\u003e\n\u003e\u003e A stamped tranasction has a stamp, an unstamped transaction has no stamp.\n\u003e\u003e The stamped transaction is larger because of the stamp.\n\u003e\u003e Larger transactions are more expensive because fees.\n\u003e\u003e\n\u003e\u003e Thus, stamped transactions are more expensive than unstamped transactions.\n\u003e\u003e\n\u003e\u003e Convince me why I would make *my* transaction stamped when I can just\n\u003e\u003e convince *everyone else* to stamp *their* transactions and use unstamped\n\u003e\u003e transactions myself.\n\u003e\u003e\n\u003e\u003e If you propose that all transactions must be stamped in a new version of\n\u003e\u003e Bitcoin, then take note that users will prefer to run older versions and\n\u003e\u003e never upgrade to the new version that requires stamped transactions.\n\u003e\u003e Why should users prefer a more expensive transaction format?\n\u003e\u003e For the good of the network?\n\u003e\u003e That is precisely an incentives problem: if it is so good for the\n\u003e\u003e network, then it should be good for an individual user, because the network\n\u003e\u003e is made up of individual users anyway; if individual users are not\n\u003e\u003e incentivized to use it, then that fact suggests it might not be as good for\n\u003e\u003e the network as you might think.\n\u003e\u003e\n\u003e\u003e If you answer \"the stamp can be discounted\" then be aware that validating\n\u003e\u003e the stamp is still a cost on every node, and it is that cost that we want\n\u003e\u003e to be reflected in pricing every byte in the transaction.\n\u003e\u003e For instance, UTXOs are retained, potentially indefinitely, and the UTXO\n\u003e\u003e lookup structure has to be very fast and is referred to at every\n\u003e\u003e transaction validation, so outputs (which create new UTXO entries) in\n\u003e\u003e SegWit are 4x more expensive than signatures, since signatures are only\n\u003e\u003e validated once when the transaction is queued to be put in the mempool.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e \u003e Mempool\n\u003e\u003e \u003e It's bad of me that I don't really know how mempool works in Bitcoin.\n\u003e\u003e My assumption is that there are some junk transactions (transactions that\n\u003e\u003e are valid but have very low or zero fees) inside the mempool. Stamping\n\u003e\u003e transactions might help to get rid of them time to time.\n\u003e\u003e\n\u003e\u003e Why would you think that stamping reduces mempool size?\n\u003e\u003e\n\u003e\u003e If I wanted to I could just re-send the transaction with a fresh stamp.\n\u003e\u003e Then the mempool usage would still be the same, and bandwidth use will\n\u003e\u003e increase (because the same transaction is now re-broadcast with a fresh\n\u003e\u003e stamp, and the added size of the stamps themselves).\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e Regards,\n\u003e\u003e ZmnSCPxj\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200609/158605a4/attachment.html\u003e",
"sig": "c52df56b2de796cedc8ddf1e1a95cf53561e577f5895b7991cba62264ef2013bf10de2e3b16716d1da6f64c6bd1d7ff996c61ee5a7c26fda3f036e011a9565a4"
}