path: root/b2/00ef35df6ed67d29d4b9cd6210a8142f5d1591

Return-Path: <psharp.x13@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 5AC28B13
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 26 Sep 2017 01:33:28 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yw0-f175.google.com (mail-yw0-f175.google.com
	[209.85.161.175])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 85F7B3DB
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 26 Sep 2017 01:33:26 +0000 (UTC)
Received: by mail-yw0-f175.google.com with SMTP id v72so6062943ywa.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 25 Sep 2017 18:33:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc; bh=JeYSPS9nS4F3ExzPlRRBjnS7VfFYq5YhZv75GlVbNmw=;
	b=plHfZ0UBTAqWmtpE8bO137Box53S1KWq8hQiDyOAqplusfqZscN9N8e7ZlD29nS1tY
	WJtaVGZpi9jSxlxJdFna2wd7GUTNM0KcQMezTINws+Om+a68z8CBTeRKsbSZsKfDR896
	xATOTFxbU++Eo+on2RzObgJfd4qnflSk2lyDH1e3419TMJLyvesRljxncKQwZZPlAN7K
	Wkt9psrvnAtvfztP+4E7fB+hbyQvbU8N2PbDiUgapIEiV2QvTh+JqFueQFVG99Dc3pXM
	UNFrwbgOEWgrnHWuezONKSZM3C2wUNBoyu75Y7DyQPqyoBbXxCAP5P8Id1MMyhR5RCrv
	CQ5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc;
	bh=JeYSPS9nS4F3ExzPlRRBjnS7VfFYq5YhZv75GlVbNmw=;
	b=Qu4hutVk3JOOPHOZ7ga9t1u4A60uo9rMHUIU5BIa9G3toThh+M1AqIJjz8Bwz27d3P
	BAT/zMpXDepni70UszYkhjvhk0K0MDYrWUJPZ1tt9+Duw+f8Ad7GHf0AAsMXzRCZ/Q4f
	s8nRsnkaRVRMioK3Xm1oxZgAK19Scz98Wpv6cNuPXT0OE42vVA4hrH9f9FsvqIJtpLTQ
	kxFoiYCIT0jx/4EPS46powLX1CqUJLC/wX8WJiKopzpRsb5fYdZb0S39sQEyoA9dL6tQ
	KjFffOiy75z2nPDc0kUqqk+m3mjwvbpFhucZRj+2rfCAzA+TSDjI2GDYgqJ73DRNnLbO
	Lv8w==
X-Gm-Message-State: AHPjjUiBost9YsgqLOGhnATetMGWRxXhJV2vebA7OLdsjzgy8za7CbMr
	UVkwDsEhCHB7h1uq6bbd/bL8yiY5qwXU6inuqxuvxH5n
X-Google-Smtp-Source: AOwi7QA32wXVHJrGYvKLQ5KEfuiEFXNCVcO60gr0KqNRzyFSVJ+Krd0AlA8LEKy+PJMIHvG6t6lcqDQCN+2pGcoxuEc=
X-Received: by 10.13.212.200 with SMTP id w191mr5955678ywd.132.1506389605605; 
	Mon, 25 Sep 2017 18:33:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.104.195 with HTTP; Mon, 25 Sep 2017 18:33:25 -0700 (PDT)
In-Reply-To: <9Rdn-Mm90LWD4Tk_F0x04feUwKQp3nL8yTou9435kqjPCwjXWzNXsYTbWDA8YvO4p6_jBu1sFXEAa1ybvtcIrOqbv7qkghwENdHch6n_EEM=@protonmail.com>
References: <CAES+R-qpBwXdROKnXW0idierJYf7pSRe3Z=KSYvcGwB_S6nXrA@mail.gmail.com>
	<9Rdn-Mm90LWD4Tk_F0x04feUwKQp3nL8yTou9435kqjPCwjXWzNXsYTbWDA8YvO4p6_jBu1sFXEAa1ybvtcIrOqbv7qkghwENdHch6n_EEM=@protonmail.com>
From: Patrick Sharp <psharp.x13@gmail.com>
Date: Mon, 25 Sep 2017 19:33:25 -0600
Message-ID: <CAES+R-rWiyn65+HYadu+OVBuG0zDeuw+0GN404rZ233CSEFVxA@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="001a114fd42055e5dd055a0da97d"
X-Spam-Status: No, score=0.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=disabled version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Tue, 26 Sep 2017 02:05:46 +0000
Cc: "bitcoin-dev@lists.linuxfoundation.org"
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] idea post: trimming and demurrage
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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, 26 Sep 2017 01:33:28 -0000

--001a114fd42055e5dd055a0da97d
Content-Type: text/plain; charset="UTF-8"

Thank you for your responses. I have been enlightened. For the time being
the combination of the UTXO's and pruning will accomplish what I desire. I
suspect that there will come a time when the UTXO database becomes too
large, but I guess that is a problem for another day. If that day ever
comes 10 years was just an example, like you said there are reasons to
preserve value beyond that point, perhaps a human lifetime or two would be
a better choice.

Side question: wouldn't it be a good idea to store the hash of the current
or previous UTXO's in the block header so that pruned nodes can verify
their UTXO's are accurate without having to check the full chain? and/or
maybe include a snap shot of the UTXO's every x blocks?

You guys are totally awesome!!!

I here by withdraw my proposal for the time being.

On Mon, Sep 25, 2017 at 5:34 PM, ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> Good morning Patrick,
>
> Demurrage is simply impossible.
>
> In Bitcoin we already have implemented OP_CHECKLOCKTIMEVERIFY.
>
> This opcode requires that a certain block height or date has passed before
> the output can be spent.
>
> It can be used to make an "in trust for" address, where you disallow
> spending of that address.  For example, you may have a child to whom you
> wish to dedicate some inheritance to, and ensure that the child will not
> spend it recklessly until they achieve some age (when hopefully they would
> be more mature), regardless of what happens to you.
>
> If I made a P2SH address with OP_CHECKLOCKTIMEVERIFY that allows spending
> 18 years from birth of my child, and then suddenly Bitcoin Core announces
> demurrage, I would be very angry.
>
> OP_CHECKLOCKTIMEVERIFY cannot be countermanded, and it would be impossible
> to refresh the UTXO's as required by demurrage, without requiring a
> hardfork that ignores OP_CHECKLOCKTIMEVERIFY.
>
> It would be better to put such additional features as demurrage in a
> sidechain rather than on mainchain.
>
>
> Regards,
> ZmnSCPxj
>
> -------- Original Message --------
> Subject: [bitcoin-dev] idea post: trimming and demurrage
> Local Time: September 25, 2017 9:54 PM
> UTC Time: September 25, 2017 9:54 PM
> From: bitcoin-dev@lists.linuxfoundation.org
> To: bitcoin-dev@lists.linuxfoundation.org
>
> Hello Devs,
>
> I am Patrick Sharp. I just graduated with a BS is computer science.
> Forgive my ignorance.
>
> As per bip-0002 I have scoured each bip available on the wiki to see if
> these ideas have already been formally proposed and now as per bip-0002
> post these ideas here.
>
> First and foremost I acknowledge that these ideas are not original nor new.
>
> Trimming and demurrage:
>
> I am fully aware that demurrage is a prohibited change. I hereby contest.
> For the record I am not a miner, I am just aware of the economics that
> drive the costs of bitcoin.
>
> Without the ability to maintain some sort of limit on the maximum length
> or size of the block chain, block chain is not only unsustainable in the
> long run but becomes more and more centralized as the block chain becomes
> more and more unwieldy.
>
> Trimming is not a foreign concept. Old block whose transactions are now
> spent hold no real value. Meaningful trimming is expensive and inhibited by
> unspent transactions. Old unspent transactions add unnecessary and unfair
> burden.
> Old transactions take up real world space that continues incur cost while
> these transactions they do not continue to contribute to any sort of
> payment for this cost.
> One can assume that anybody with access to their bitcoins has the power to
> move these bitcoins from one address to another (or at least that the
> software that holds the keys to their coins can do it for them) and it is
> not unfair to require them to do so at least once every 5 to 10 years.
> Given the incentive to move it or lose it and software that will do it for
> them, we can assume that any bitcoin not moved is most likey therefore lost.
> moving these coins will cost a small transaction fee which is fair as
> their transactions take up space, they need to contribute
> most people who use their coins regularly will not even need to worry
> about this as their coins are moved to a change address anyway.
> one downside is that paper wallets would then have an expiration date,
> however I do not think that a paper wallet that needs to be recycled every
> 5 to 10 years is a terrible idea.
> Therefore I propose that the block chain length be limited to either 2^18
> blocks (slightly less than 5 years) or 2^19 blocks, or slightly less than
> 10 years. I propose that each time a block is mined the the oldest block(s)
> (no more than two blocks) beyond this limit is trimmed from the chain and
> that its unspent transactions are allowed to be included in the reward of
> the mined block.
>
> This keeps the block chain from tending towards infinity. This keeps the
> costs of the miners balanced with the costs of the users.
>
> Even though I believe this idea will have some friction, it is applicable
> to the entire community. It will be hard for some users to give up small
> benefits that they get at the great cost of miners, however miners run the
> game and this fair proposal is in in their best interest in two different
> ways. I would like your thoughts and suggestions. I obviously think this is
> a freaking awesome idea. I know it is quite controversial but it is the
> next step in evolution that bitcoin needs to take to ensure immortality.
>
> I come to you to ask if this has any chance of acceptance.
>
> -Patrick
>

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

<div dir=3D"ltr"><div style=3D""><span style=3D"font-size:12.8px">Thank you=
 for your responses. I have been enlightened. For the time being the combin=
ation of the UTXO&#39;s and=C2=A0pruning will accomplish=C2=A0what I desire=
. I suspect that there will come a time when the UTXO database becomes too =
large, but I guess that is a problem for another day. If that day ever come=
s 10 years was just an example, like you said there are reasons to preserve=
 value beyond that point, perhaps a human lifetime or two would be a better=
 choice.</span></div><div style=3D"font-size:12.8px"><span style=3D"font-si=
ze:12.8px"><br></span></div><div style=3D"font-size:12.8px">Side question: =
wouldn&#39;t it be a good idea to store the hash of the current or previous=
 UTXO&#39;s in the block header so that pruned nodes can verify their UTXO&=
#39;s are accurate without having to check the full chain? and/or maybe inc=
lude a snap shot of the UTXO&#39;s every x blocks?</div><div style=3D"font-=
size:12.8px"><br></div><div style=3D"font-size:12.8px"><span style=3D"font-=
size:12.8px">You guys are totally awesome!!!</span></div><div style=3D"font=
-size:12.8px"><br></div><div style=3D"font-size:12.8px">I here by withdraw =
my proposal for the time being.</div></div><div class=3D"gmail_extra"><br><=
div class=3D"gmail_quote">On Mon, Sep 25, 2017 at 5:34 PM, ZmnSCPxj <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:ZmnSCPxj@protonmail.com" target=3D"_blank"=
>ZmnSCPxj@protonmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">Good morning Patrick,<br><br>Demurrage is simply impossible.<br><br>I=
n Bitcoin we already have implemented OP_CHECKLOCKTIMEVERIFY.<br><br>This o=
pcode requires that a certain block height or date has passed before the ou=
tput can be spent.<br><br>It can be used to make an &quot;in trust for&quot=
; address, where you disallow spending of that address.=C2=A0 For example, =
you may have a child to whom you wish to dedicate some inheritance to, and =
ensure that the child will not spend it recklessly until they achieve some =
age (when hopefully they would be more mature), regardless of what happens =
to you.<br><br>If I made a P2SH address with OP_CHECKLOCKTIMEVERIFY that al=
lows spending 18 years from birth of my child, and then suddenly Bitcoin Co=
re announces demurrage, I would be very angry.<br><br>OP_CHECKLOCKTIMEVERIF=
Y cannot be countermanded, and it would be impossible to refresh the UTXO&#=
39;s as required by demurrage, without requiring a hardfork that ignores OP=
_CHECKLOCKTIMEVERIFY.<br><br>It would be better to put such additional feat=
ures as demurrage in a sidechain rather than on mainchain.<br><div><br></di=
v><div><br></div><div>Regards,<br></div><div>ZmnSCPxj<br></div><div class=
=3D"HOEnZb"><div class=3D"h5"><div><br></div><div>-------- Original Message=
 --------<br></div><div>Subject: [bitcoin-dev] idea post: trimming and demu=
rrage<br></div><div>Local Time: September 25, 2017 9:54 PM<br></div><div>UT=
C Time: September 25, 2017 9:54 PM<br></div><div>From: <a href=3D"mailto:bi=
tcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.<w=
br>linuxfoundation.org</a><br></div><div>To: <a href=3D"mailto:bitcoin-dev@=
lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfo=
undation.org</a><br></div><div><br></div><div>Hello Devs,<br></div><div><br=
></div><div>I am Patrick Sharp. I just graduated with a BS is computer scie=
nce. Forgive my ignorance.<br></div><div><br></div><div>As per bip-0002 I h=
ave scoured each bip available on the wiki to see if these ideas have alrea=
dy been formally proposed and now as per bip-0002 post these ideas here.<br=
></div><div><br></div><div>First and foremost I acknowledge that these idea=
s are not original nor new.<br></div><div><br></div><div>Trimming and demur=
rage:<br></div><div><br></div><div>I am fully aware that demurrage is a pro=
hibited change. I hereby contest. For the record I am not a miner, I am jus=
t aware of the economics that drive the costs of bitcoin.<br></div><div><br=
></div><div>Without the ability to maintain some sort of limit on the maxim=
um length or size of the block chain, block chain is not only unsustainable=
 in the long run but becomes more and more centralized as the block chain b=
ecomes more and more unwieldy.<br></div><div><br></div><div>Trimming is not=
 a foreign concept. Old block whose transactions are now spent hold no real=
 value. Meaningful trimming is expensive and inhibited by unspent transacti=
ons. Old unspent transactions add unnecessary and unfair burden.<br></div><=
div>Old transactions take up real world space that continues incur cost whi=
le these transactions they do not continue to contribute to any sort of pay=
ment for this cost.<br></div><div>One can assume that anybody with access t=
o their bitcoins has the power to move these bitcoins from one address to a=
nother (or at least that the software that holds the keys to their coins ca=
n do it for them) and it is not unfair to require them to do so at least on=
ce every 5 to 10 years.<br></div><div>Given the incentive to move it or los=
e it and software that will do it for them, we can assume that any bitcoin =
not moved is most likey therefore lost.<br></div><div>moving these coins wi=
ll cost a small transaction fee which is fair as their transactions take up=
 space, they need to contribute<br></div><div>most people who use their coi=
ns regularly will not even need to worry about this as their coins are move=
d to a change address anyway.<br></div><div>one downside is that paper wall=
ets would then have an expiration date, however I do not think that a paper=
 wallet that needs to be recycled every 5 to 10 years is a terrible idea.<b=
r></div><div>Therefore I propose that the block chain length be limited to =
either 2^18 blocks (slightly less than 5 years) or 2^19 blocks, or slightly=
 less than 10 years. I propose that each time a block is mined the the olde=
st block(s) (no more than two blocks) beyond this limit is trimmed from the=
 chain and that its unspent transactions are allowed to be included in the =
reward of the mined block.<br></div><div><br></div><div>This keeps the bloc=
k chain from tending towards infinity. This keeps the costs of the miners b=
alanced with the costs of the users.<br></div><div><br></div><div>Even thou=
gh=C2=A0I believe this idea will have some friction, it is applicable to th=
e entire community. It will be hard for some users to give up small benefit=
s that they get at the great cost of miners, however miners run the game an=
d this fair proposal is in in their best interest in two different ways. I =
would like your thoughts and suggestions. I obviously think this is a freak=
ing awesome idea. I know it is quite controversial=C2=A0but it is the next =
step in evolution that bitcoin needs to take to ensure immortality.<br></di=
v><div><br></div><div>I come to you to ask if this has any chance of accept=
ance.<br></div><div><br></div><div>-Patrick<br></div></div></div></blockquo=
te></div><br></div>

--001a114fd42055e5dd055a0da97d--