path: root/a4/eed14a5c123f0c0d443d06615f25c439b3d452

Return-Path: <criley@gmail.com>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 04914C016F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  9 Jun 2020 14:16:57 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hemlock.osuosl.org (Postfix) with ESMTP id EED4F87BCA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  9 Jun 2020 14:16:56 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 0vchC5ROHh4I
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  9 Jun 2020 14:16:55 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ej1-f45.google.com (mail-ej1-f45.google.com
 [209.85.218.45])
 by hemlock.osuosl.org (Postfix) with ESMTPS id EBF7F87B8E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  9 Jun 2020 14:16:54 +0000 (UTC)
Received: by mail-ej1-f45.google.com with SMTP id n24so22577553ejd.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 09 Jun 2020 07:16:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=4thZbBmE0Pj6lqLEjpeYoPuR8CXD9AZj87wSoYm3kv0=;
 b=WBXy9FBP6ZygWC6W6nZHkqyRb5ydBbvldW29YLVjazcOkbQpu4NU9w8HrmfXL9sH5n
 N3cjiQdmtakewVzhBx0GGt1aICkzZ6+b9czobi3S36J7oSpce0f/+/xPUcceqH3xBghJ
 dbH79IHyMHDUyXe68hUHnnxUIC2XcLq0jTDDaO+IhLPCz4TTHbhkXs8cR1n+P/CY1MyJ
 LDAhMwYH4UaXb953CgA5h18GdqBH1tbbue9VPv88IZVH57bWX6fiLyGMDM8G7Bq92eT3
 HTOfqJcFkoH8Eht1d9Xc6dMrXBM4RmvTyMl4LhPWVtBtjrHzyAlzvWxq9+z4ZbBBfZ4b
 qspw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=4thZbBmE0Pj6lqLEjpeYoPuR8CXD9AZj87wSoYm3kv0=;
 b=Tu8JY7SyJ6O222TjKuWijeIUh449t9ESz4u15GmV6KAK7aedglrteXm+s2fKMMsH9a
 k1nqjcoi1PC1CKp/E3MVw+zl+m3qUef6Ak+cN/RiTTmmZCZeftF+eUdHvsiGKclIPDMF
 LbOR5NMP4fN2sASMUlC30gsI/Hip1RJ2s0V4fyUUhPMCvldLE16l0C/T0zosrEpMFUht
 ZT3wdFxcaz4ELJ3henaX1okGCdWfX9eWfFlnbVhcvpMEalr0IAE+F8Vpx1qwrXk9rgbE
 KAPVMs/AhA5J1yodEF884gNlA+YaVISTnlDPvttRljXohUDqoh0hNQvIQu6Z4BJItuf0
 FCNA==
X-Gm-Message-State: AOAM533oDX7VERQ9QcUDL689hWUZmF7j8kdcCVsdJ3ib/B1I6z+f8Mll
 EO/GUbhNS5dljbeLo75Roo24Hr7Usvz6V6O9XSE=
X-Google-Smtp-Source: ABdhPJz7xOAnPn+GvdDv5BpZqiJgotNY0mmr5DHMXXOqL9kkTO99zSvfMn9GLVXN0AlxTD7mfJiLQ7wkrpXcluixC10=
X-Received: by 2002:a17:906:2b04:: with SMTP id
 a4mr26192780ejg.98.1591712213131; 
 Tue, 09 Jun 2020 07:16:53 -0700 (PDT)
MIME-Version: 1.0
References: <CAJr8eKuFv7R-1HRft-hLFTSdpWUL2uOtkDtisL2+iPaEvvH_hA@mail.gmail.com>
 <c_8uFmqhKnoFYLB23sjYhJlKAXU5ZoCSQ2MsSgn_OePQoJKFOqIuzMjm7vhnCzevQkAwdJextCeNjA8D-f_p__-sUFSkOFMDI5_yS7k8ZM8=@protonmail.com>
 <CAJr8eKtV=W8wLkZZP9tagnL8F3jxOv8t-J9oBCFV6MrRPDmGiw@mail.gmail.com>
 <gNdtY-_W10fFe8vwyhQNUOCIWCtBj0G9LLUu5GQ7PYlRXejM1jwIX__TMYUhq6DDczOTQ3YYgVACOBSv6yIqx5nZ5vRbXkXPn-yjsOqi52w=@protonmail.com>
 <CAJr8eKuFM0QoNNaG9Tao7aVzCoXLTH+cATxaMnropjdEVFDqOw@mail.gmail.com>
In-Reply-To: <CAJr8eKuFM0QoNNaG9Tao7aVzCoXLTH+cATxaMnropjdEVFDqOw@mail.gmail.com>
From: Chris Riley <criley@gmail.com>
Date: Tue, 9 Jun 2020 10:16:27 -0400
Message-ID: <CAL5BAw3WytOEA_fiFDabwWXtCoLdNAy+nf3PV3e+sUde1nOGew@mail.gmail.com>
To: Mostafa Sedaghat joo <mostafa.sedaghat@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000000c656405a7a761a7"
X-Mailman-Approved-At: Tue, 09 Jun 2020 14:18:14 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Stamping transaction
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jun 2020 14:16:57 -0000

--0000000000000c656405a7a761a7
Content-Type: text/plain; charset="UTF-8"

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@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@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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--0000000000000c656405a7a761a7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div di=
r=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"lt=
r"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div style=3D"color:r=
gb(0,0,0)">Hello,</div><div style=3D"color:rgb(0,0,0)"><br></div><div style=
=3D"color:rgb(0,0,0)">Just a few comments.</div><div style=3D"color:rgb(0,0=
,0)"><br></div><div style=3D"color:rgb(0,0,0)">&gt;But there is no guarante=
e=C2=A0that ndes should keep all of them from the genesis. It depends. Mayb=
e some nodes want to keep=C2=A0 all the transactions, some part of them and=
 might nothing.</div><div><font color=3D"#000000"><span style=3D"caret-colo=
r: rgb(0, 0, 0);">There is no guarantee that nodes keep them all from the g=
enesis now, nodes can turn on pruning if the operator doesn&#39;t desire to=
 keep all the transactions from the genesis block (<a href=3D"https://githu=
b.com/bitc">https://github.com/bitc</a></span></font>oin/bitcoin/blob/v0.11=
.0/doc/release-notes.md#block-file-pruning).=C2=A0 Likewise, light clients =
may not keep any transaction history.<br></div><div><br>&gt;Also we can thi=
nk about check pointing. When a new node connects to the network, it doesn&=
#39;t need to validate all the blocks since genesis. It can start validatin=
g from a checkpoint. <br>&gt;Transactions have their own way to survive. Ow=
ner of the coin can keep the history of his transactions.</div><div>There h=
ave been some checkpoint discussions on here too, which have discussed the =
pros and cons of them.<br>see, e.g.:<br>site:<a href=3D"https://lists.linux=
foundation.org/pipermail/bitcoin-dev/">https://lists.linuxfoundation.org/pi=
permail/bitcoin-dev/</a> checkpointand:<br><a href=3D"https://lists.linuxfo=
undation.org/pipermail/bitcoin-dev/2018-May/016001.html">https://lists.linu=
xfoundation.org/pipermail/bitcoin-dev/2018-May/016001.html</a><br><a href=
=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017=
209.html">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-Augu=
st/017209.html</a><br><br>Without introducing trusted people, how can you p=
rove that the &quot;owner&quot; is person A or B without verification from =
the genesis block?=C2=A0 For example, A or B could claim to be the owner an=
d provide an altered client with an altered checkpoint to &quot;prove&quot;=
 it.=C2=A0</div></div><div dir=3D"ltr"><br></div><div dir=3D"ltr">&gt;Anyti=
me the bitcoin community decides to make a hard-fork, you might consider th=
is change as well<br></div><div>From reading the initial bitcoin paper, man=
y proposals etc since and having been around the &quot;bitcoin community&qu=
ot; 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 o=
f the blockchain bank. =C2=A0 Not to say this isn&#39;t a useful, interesti=
ng, informative, and educational discussion, but it seems unlikely to happe=
n.=C2=A0 Likewise, =C2=A0it could lead to something related that would be l=
ikely to occur, so full discussions like this are useful.</div><div><br></d=
iv><div>Regards, =C2=A0:-)</div><div>Chris</div><div dir=3D"ltr"><br></div>=
<div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Ju=
n 9, 2020 at 7:20 AM Mostafa Sedaghat joo via bitcoin-dev &lt;<a href=3D"ma=
ilto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundati=
on.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;borde=
r-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Good day Z=
mnSCPxj<div><br></div><div>As I said before, I don&#39;t expect a hard fork=
 for=C2=A0this 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.=C2=A0</div><div>I believe=C2=A0decoupling transactions fro=
m the block is beautiful.=C2=A0</div><div><br></div><div>=C2=A0About transa=
ction verification,</div><div>Transactions have their own way to survive. O=
wner of the=C2=A0coin can keep the history of his transactions.</div><div>B=
ut there is no guarantee=C2=A0that ndes should keep all of them from the ge=
nesis. It depends. Maybe some nodes want to keep=C2=A0 all the transactions=
, some part of them and might nothing.</div><div>Also we can think about ch=
eck pointing. When a new node connects to the network, it doesn&#39;t need =
to validate all the blocks since genesis. It can start validating from a ch=
eckpoint.=C2=A0</div><div><br></div><div>And also adding 32 bits to the hea=
der of translation=C2=A0(which won&#39;t be saved inside the block) is not =
a big deal.</div><div><br></div><div><br></div><div>Adios,</div><div>Mostaf=
a=C2=A0<br></div><div><br></div><div><br></div></div><br><div class=3D"gmai=
l_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Jun 7, 2020 at 11:01=
 PM ZmnSCPxj &lt;<a href=3D"mailto:ZmnSCPxj@protonmail.com" target=3D"_blan=
k">ZmnSCPxj@protonmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-le=
ft-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Good mo=
rning Mostafa,<br>
<br>
<br>
&gt; The main point of stamping transactions is decoupling transactions fro=
m the block.=C2=A0<br>
&gt;<br>
&gt; Blockchain size matters<br>
&gt; SegWit is a good witness that shows blockchain size matters. Nowadays,=
=C2=A0Data storage is cheap and easy, but that doesn&#39;t mean it&#39;s a =
simple matter. If you need to have a data-center to keep a copy of a blockc=
hain, then you are far from a decentralization system.=C2=A0<br>
&gt;<br>
&gt; A Solution<br>
&gt; Stamping=C2=A0transaction is a simple idea to keep the size of the blo=
ckchain as small as possible. The question that I was looking to answer is =
how we can decouple the transaction from the blocks.<br>
&gt; Who cares about the transaction that happened=C2=A010 years ago. In th=
e real world you may go to your bank and ask them to give you transaction=
=C2=A0history. But they probably have limits. They might say we just only k=
eep the last 3 months in our system.=C2=A0<br>
<br>
Stamping transaction is not how you would be able to keep **blockchain** si=
ze low.<br>
<br>
The reason why very old history is retained is that, if a new node is broug=
ht up, you need to prove to that node that you are in fact the correct owne=
r of the current coins.<br>
Thus the entire history of Bitcoin is needed when starting a new node, and =
why archive nodes exist.<br>
<br>
You might argue that banks do not do that, and that is because we want to d=
o better than banks; we know that existing currency systems have not only t=
he &quot;official&quot; minter, but also many &quot;unofficial&quot; minter=
s (commonly called counterfeiters) which dilute the value of the currency.<=
br>
It is this insistence on a full accounting of the provenance for every sato=
shi that separates Bitcoin from previous currency systems; bank fraud exist=
s, and it hides in such sloppy techniques as deleting old transaction recor=
ds.<br>
<br>
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 histor=
y of your coin to the payee, instead of everyone validating every transacti=
on).<br>
Look up Peter Todd for some initial work on this.<br>
<br>
<br>
&gt; Implementation<br>
&gt;<br>
&gt; &gt; First off, the proposed mechanism can be made into a softfork by =
using an unspendable `scriptPubKey` with 0 output value.<br>
&gt; SoftFork is not possible here. Because the transaction will not be sav=
ed inside the block (only tx hashes). Block format needs to be changed. The=
refore the block will be invalid.<br>
<br>
That greatly reduces the chances your proposal will get into Bitcoin; you w=
ould need to have very good advantages to counterbalance the tremendous ris=
k that hardforks introduce in the continuity of the coin.<br>
<br>
Bitcoin has never gone through a hardfork that has not instead created a ne=
w cryptocurrency, so any solution that requires a hardfork is going to be u=
nlikely to be accepted by everyone.<br>
<br>
&gt; &gt;=C2=A0Engineering-wise, block validation now needs to memorize the=
 last N block hashes.<br>
&gt; I don&#39;t think we need to memorize the last N block hashes.=C2=A0 W=
e can have something like:<br>
&gt; ```<br>
&gt; Current_Height - Height_Of(tx.stamp) &lt;=3D N=C2=A0<br>
&gt; ```<br>
<br>
...<br>
<br>
<br>
`Height_Of()` would basically be a mapping from block hashes to block heigh=
ts, with the number of elements equal to the height of the blockchain, and =
thus continuously growing.<br>
Thus, validation is expected to become more expensive as the blockchain gro=
ws.<br>
<br>
Since stamped transactions have a time-to-live anyway, instead you can use =
a *set* of the most recent N block hashes.<br>
Then you simply check if the stamp is in the set.<br>
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.<br>
<br>
&gt; Incentives<br>
&gt; I think Stamping transactions have nothing to do with the incentivizat=
ion=C2=A0mechanism.=C2=A0 Forgive me if I couldn&#39;t get your point.<br>
<br>
A stamped tranasction has a stamp, an unstamped transaction has no stamp.<b=
r>
The stamped transaction is larger because of the stamp.<br>
Larger transactions are more expensive because fees.<br>
<br>
Thus, stamped transactions are more expensive than unstamped transactions.<=
br>
<br>
Convince me why I would make *my* transaction stamped when I can just convi=
nce *everyone else* to stamp *their* transactions and use unstamped transac=
tions myself.<br>
<br>
If you propose that all transactions must be stamped in a new version of Bi=
tcoin, then take note that users will prefer to run older versions and neve=
r upgrade to the new version that requires stamped transactions.<br>
Why should users prefer a more expensive transaction format?<br>
For the good of the network?<br>
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.<br>
<br>
If you answer &quot;the stamp can be discounted&quot; then be aware that va=
lidating 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.<br>
For instance, UTXOs are retained, potentially indefinitely, and the UTXO lo=
okup 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 mor=
e expensive than signatures, since signatures are only validated once when =
the transaction is queued to be put in the mempool.<br>
<br>
<br>
&gt; Mempool<br>
&gt; It&#39;s bad of me that I don&#39;t really know how mempool works in B=
itcoin. My assumption is that there are some junk transactions (transaction=
s that are valid but have very low or zero fees) inside the mempool. Stampi=
ng transactions might help to get rid of them time to time.=C2=A0<br>
<br>
Why would you think that stamping reduces mempool size?<br>
<br>
If I wanted to I could just re-send the transaction with a fresh stamp.<br>
Then the mempool usage would still be the same, and bandwidth use will incr=
ease (because the same transaction is now re-broadcast with a fresh stamp, =
and the added size of the stamps themselves).<br>
<br>
<br>
Regards,<br>
ZmnSCPxj<br>
<br>
</blockquote></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div></div></div></div></div></div></div></div></div></=
div></div>

--0000000000000c656405a7a761a7--