+Return-Path: <mark@friedenbach.org>

+Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org

+ [172.17.192.35])

+ by mail.linuxfoundation.org (Postfix) with ESMTPS id E15908D7

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Wed, 23 Aug 2017 03:26:23 +0000 (UTC)

+X-Greylist: whitelisted by SQLgrey-1.7.6

+Received: from mail-pf0-f173.google.com (mail-pf0-f173.google.com

+ [209.85.192.173])

+ by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D2F653F9

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Wed, 23 Aug 2017 03:26:23 +0000 (UTC)

+Received: by mail-pf0-f173.google.com with SMTP id c28so2193366pfe.3

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Tue, 22 Aug 2017 20:26:23 -0700 (PDT)

+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;

+ d=friedenbach-org.20150623.gappssmtp.com; s=20150623;

+ h=mime-version:subject:from:in-reply-to:date:cc

+ :content-transfer-encoding:message-id:references:to;

+ bh=GLpEc/z6vePOrJaAOnKLd1cE9ZBza0c6uZXAfjyPEHo=;

+ b=LXmvIUd31XGkmwBBtyx2EqN0Wp4OwklxQSV02C/ilOc8E5/KgveLHjAf05TlXZ7oBI

+ kHBfn9NsOyF2A4MU2NVn9u5LNBb08aTaGy+CUpKQWhWrFtAN9ZRjtSdUJMBLOwuxV+/0

+ vIhbz+/VPugjoynMEt46ZRm9ekUjX1cU6LDABIWXc1Cp+cebbN2hdzhalfJjFdEVTlaK

+ 3NXLZENLjtThPFSfZ/s6WhIlM5D26pQiYMsKgv7KVPVpu2mdHL1ZUtzVrSHCnrSmvM27

+ R1Cuvtm6mFzPbxgeC1gU0UfbmGSkWDphBOLEE5QUitkidtbHxuoad0vcc0NU0oQF2wce

+ 4OBA==

+X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;

+ d=1e100.net; s=20161025;

+ h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc

+ :content-transfer-encoding:message-id:references:to;

+ bh=GLpEc/z6vePOrJaAOnKLd1cE9ZBza0c6uZXAfjyPEHo=;

+ b=OnLtxEccpjdC+Xtv0hm9Inb1yRqX2b3yCAjqlSmlI0Q4KgjlKMfeFf23ClvvU7a4Pl

+ KVcdt2AUt/j7UU8bcLyhl2sGBLtVsMj7upO+ejZhZpsWRUZ1riDyp3+HP3ScLTglN398

+ tgx8DH365TR8IphXqyfaVWzXdoUt6vlaiFlIJcr6ZMBXu6A1Yf1CFz1F08M+Gkl+sMuL

+ EPQVbN0Kfymv3RPq0UPpmndemtG26orfEfLXYviDZ9lsPYzdBNDrEIpk5MAaYqJCrXto

+ PSV/c8c07mkI2ZuEUR5peXc+qBAxQx5nwqDcxVIi6aXUv6+BAODaw9fblyiZBMfQL3GU

+ fAeQ==

+X-Gm-Message-State: AHYfb5jfWcnsA+xtZLBJlojU/kMskjb0r/XBWf+iRAwTkwN3tMjC0Xl9

+ kWwEt+lSIOY0t0zS

+X-Received: by 10.99.117.12 with SMTP id q12mr1248523pgc.59.1503458783360;

+ Tue, 22 Aug 2017 20:26:23 -0700 (PDT)

+Received: from ?IPv6:2601:646:8080:1291:69bc:9ed4:458d:cfa6?

+ ([2601:646:8080:1291:69bc:9ed4:458d:cfa6])

+ by smtp.gmail.com with ESMTPSA id g14sm551705pfm.77.2017.08.22.20.26.20

+ (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);

+ Tue, 22 Aug 2017 20:26:21 -0700 (PDT)

+Content-Type: multipart/alternative;

+ boundary=Apple-Mail-70C4233B-5D3D-45BF-B08D-F385931D727B

+Mime-Version: 1.0 (1.0)

+From: Mark Friedenbach <mark@friedenbach.org>

+X-Mailer: iPhone Mail (14G60)

+In-Reply-To: <f440fb62-4837-b98d-15e5-fd871ce3869e@aei.ca>

+Date: Tue, 22 Aug 2017 20:26:19 -0700

+Content-Transfer-Encoding: 7bit

+Message-Id: <02ECA1E2-B113-4668-984A-70445052C8B9@friedenbach.org>

+References: <CABerxhG6HTZF+J5f0R3cpLvMjFW06p7ar_JGX9Oidokz-PT4=g@mail.gmail.com>

+ <f440fb62-4837-b98d-15e5-fd871ce3869e@aei.ca>

+To: Thomas Guyot-Sionnest <dermoth@aei.ca>,

+ Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>

+X-Mailman-Approved-At: Wed, 23 Aug 2017 03:28:04 +0000

+Cc: Rodney Morris <rodney.morris@gmail.com>

+Subject: Re: [bitcoin-dev] UTXO growth scaling solution proposal

+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: Wed, 23 Aug 2017 03:26:24 -0000

+

+

+--Apple-Mail-70C4233B-5D3D-45BF-B08D-F385931D727B

+Content-Type: text/plain;

+ charset=us-ascii

+Content-Transfer-Encoding: quoted-printable

+

+Lock time transactions have been valid for over a year now I believe. In any=

+ case we can't scan the block chain for usage patterns in UTXOs because P2SH=

+ puts the script in the signature on spend.

+

+> On Aug 22, 2017, at 4:29 PM, Thomas Guyot-Sionnest via bitcoin-dev <bitcoi=

+n-dev@lists.linuxfoundation.org> wrote:

+>=20

+> I'm just getting the proposal out... if we decide to go forward (pretty hu=

+ge "if" right now) whenever it kicks in after 15, 50 or 100 years should be d=

+ecided as early as possible.

+>=20

+> Are CheckLockTimeVerify transactions accepted yet? I thought most special t=

+ransactions were only accepted on Testnet... In any case we should be able t=

+o scan the blockchain and look for any such transaction. And I hate to make t=

+his more complex, but maybe re-issuing the tx from coinbase could be an opti=

+on?

+>=20

+> --

+> Thomas

+>=20

+>> On 22/08/17 06:58 PM, Rodney Morris via bitcoin-dev wrote:

+>> Thomas et.al.

+>>=20

+>> So, in your minds, anyone who locked up coins using CLTV for their child t=

+o receive on their 21st birthday, for the sake of argument, has effectively f=

+orfeit those coins after the fact? You are going to force anyone who took c=

+oins offline (cryptosteel, paper, doesn't matter) to bring those coins back o=

+nline, with the inherent security risks?

+>>=20

+>> In my mind, the only sane way to even begin discussing an approach implem=

+enting such a thing - where coins "expire" after X years - would be to give t=

+he entire ecosystem X*N years warning, where N > 1.5. I'd also suggest X wo=

+uld need to be closer to the life span of a human than zero. Mind you, I'd s=

+uggest this "feature" would need to be coded and deployed as a future-hard-f=

+ork X*N years ahead of time. A-la Satoshi's blog post regarding increasing b=

+lock size limit, a good enough approximation would be to add a block height c=

+heck to the code that approximates X*N years, based on 10 minute blocks. Th=

+e transparency around such a change would need to be radical and absolute.

+>>=20

+>> I'd also suggest that, similar to CLTV, it only makes sense to discuss cr=

+eating a "never expire" transaction output, if such a feature were being ser=

+iously considered.

+>>=20

+>> If you think discussions around a block size increase were difficult, the=

+n we'll need a new word to describe the challenges and vitriol that would ar=

+ise in arguments that will follow this discussion should it be seriously pro=

+posed, IMHO.

+>>=20

+>> I also don't think it's reasonable to conflate the discussion herein with=

+ discussion about what to do when ECC or SHA256 is broken. The weakening/br=

+eaking of ECC poses a real risk to the stability of Bitcoin - the possible r=

+elease of Satoshi's stash being the most obvious example - and what to do ab=

+out that will require serious consideration when the time comes. Even if th=

+e end result is the same - that coins older than "X" will be invalidated - e=

+verything else important about the scenarios are different as far as I can s=

+ee.

+>>=20

+>> Rodney

+>>=20

+>=20

+> _______________________________________________

+> bitcoin-dev mailing list

+> bitcoin-dev@lists.linuxfoundation.org

+> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

+

+--Apple-Mail-70C4233B-5D3D-45BF-B08D-F385931D727B

+Content-Type: text/html;

+ charset=utf-8

+Content-Transfer-Encoding: 7bit

+

+<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Lock time transactions have been valid for over a year now I believe. In any case we can't scan the block chain for usage patterns in UTXOs because P2SH puts the script in the signature on spend.<br></div><div><br>On Aug 22, 2017, at 4:29 PM, Thomas Guyot-Sionnest via bitcoin-dev &lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br><br></div><blockquote type="cite"><div>

+

+ <meta content="text/html; charset=windows-1252" http-equiv="Content-Type">

+

+

+ I'm just getting the proposal out... if we decide to go forward

+ (pretty huge "if" right now) whenever it kicks in after 15, 50 or

+ 100 years should be decided as early as possible.<br>

+ <br>

+ Are CheckLockTimeVerify transactions accepted yet? I thought most

+ special transactions were only accepted on Testnet... In any case we

+ should be able to scan the blockchain and look for any such

+ transaction. And I hate to make this more complex, but maybe

+ re-issuing the tx from coinbase could be an option?<br>

+ <br>

+ --<br>

+ Thomas<br>

+ <br>

+ <div class="moz-cite-prefix">On 22/08/17 06:58 PM, Rodney Morris via

+ bitcoin-dev wrote:<br>

+ </div>

+ <blockquote cite="mid:CABerxhG6HTZF+J5f0R3cpLvMjFW06p7ar_JGX9Oidokz-PT4=g@mail.gmail.com" type="cite">

+ <div dir="ltr">

+ <div>Thomas <a moz-do-not-send="true" href="http://et.al">et.al</a>.</div>

+ <div><br>

+ </div>

+ <div>So, in your minds, anyone who locked up coins using CLTV

+ for their child to receive on their 21st birthday, for the

+ sake of argument, has effectively forfeit those coins after

+ the fact?&nbsp; You are going to force anyone who took coins

+ offline (cryptosteel, paper, doesn't matter) to bring those

+ coins back online, with the inherent security risks?</div>

+ <div><br>

+ </div>

+ <div>In my mind, the only sane way to even begin discussing an

+ approach implementing such a thing - where coins "expire"

+ after X years - would be to give the entire ecosystem X*N

+ years warning, where N &gt; 1.5.&nbsp; I'd also suggest X would

+ need to be closer to the life span of a human than zero.&nbsp; Mind

+ you, I'd suggest this "feature" would need to be coded and

+ deployed as a future-hard-fork X*N years ahead of time.&nbsp; A-la

+ Satoshi's blog post regarding increasing block size limit, a

+ good enough approximation would be to add a block height check

+ to the code that approximates X*N years, based on 10 minute

+ blocks.&nbsp; The transparency around such a change would need to

+ be radical and absolute.</div>

+ <div><br>

+ </div>

+ <div>I'd also suggest that, similar to CLTV, it only makes sense

+ to discuss creating a "never expire" transaction output, if

+ such a feature were being seriously considered.</div>

+ <div><br>

+ </div>

+ <div>If you think discussions around a block size increase were

+ difficult, then we'll need a new word to describe the

+ challenges and vitriol that would arise in arguments that will

+ follow this discussion should it be seriously proposed, IMHO.</div>

+ <div><br>

+ </div>

+ <div>I also don't think it's reasonable to conflate the

+ discussion herein with discussion about what to do when ECC or

+ SHA256 is broken.&nbsp; The weakening/breaking of ECC poses a real

+ risk to the stability of Bitcoin - the possible release of

+ Satoshi's stash being the most obvious example - and what to

+ do about that will require serious consideration when the time

+ comes.&nbsp; Even if the end result is the same - that coins older

+ than "X" will be invalidated - everything else important about

+ the scenarios are different as far as I can see.</div>

+ <div><br>

+ </div>

+ <div>Rodney</div>

+ <br>

+ </div>

+ </blockquote>

+ <br>

+

+

+</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>bitcoin-dev mailing list</span><br><span><a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a></span><br><span><a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a></span><br></div></blockquote></body></html>

+--Apple-Mail-70C4233B-5D3D-45BF-B08D-F385931D727B--

+