Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 24F28A74 for ; Thu, 7 Sep 2017 10:32:23 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f49.google.com (mail-oi0-f49.google.com [209.85.218.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 98D42D3 for ; Thu, 7 Sep 2017 10:32:22 +0000 (UTC) Received: by mail-oi0-f49.google.com with SMTP id n18so56123201oig.2 for ; Thu, 07 Sep 2017 03:32:22 -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; bh=N16fXnjPzeVrOrUQ6EVUfTNxiRTczGtld62faZgufqc=; b=Quy0Xkkqh6pabPqvy0MzVuGMb+nV3SnA7gavqe5yv2A3z/idsVFCeK+bMK2r7eyYgQ C66H5mEmjmalQDGAbNkEWXWp4SJ57JhNg6Z5ktLd3gMEtOT0Uz0Sn+RPJ5IhqMM6GAqP M6YBbETLBwkXK6kTPPKWj49mvdEi94ESi1S3Osax6SVJp2/Ry8pohdxG9QYFoWcA64i7 dwhZeNUs3ovjo7S0/UinZkYLZza7SxNS2myCwpF95AWaYPZdtfRVQV8Oiwvg699Ep6+g MEPZaoEhMbfyAxSqFS+s7Zd2Vqe/oJyuMUmxQAWtoqY34bkFmWpMls/h4t2HVhsmDjoB y9gQ== 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; bh=N16fXnjPzeVrOrUQ6EVUfTNxiRTczGtld62faZgufqc=; b=I1tMSx8uEhjqfjsP8ZZoz8h4lDWkYSFUcRF+p3QrHxGQFSXc6j4V0KuavgeWQdUAuB KqUx7ECrmhyeUN6yUcenWRtUEdRx4w3tN6db2o1zMN0jXwcCigUDbaBO6XMaeBC2SMJl cZgbvulIPhh9H3tkmDh3acf4ByyPfpcFSo5+BiJFdMPTE8aPVu8MxyY5wSpg1tM9HV/R mqGjIe9Pn/sWOVRLmdMAQzrO0kZ2fEgBkNlQQ6gStfdafknZCgW4p65Vo0alqiR3sXbl sc9gfBYei13gtSQI8i5ZZdm4ZWzwJy1s5VkFYpn153RQ9zoifT+Z8urbuGWrZ0nSVNWk ZacQ== X-Gm-Message-State: AHPjjUjPKUbg26jgkM25GLjWo1NPDt+6C5sc6o/yeG8xWC56QLV/lSBW PLZRrhUqXVuI/B3a5waBddAKGtVEew== X-Google-Smtp-Source: ADKCNb4TNqI1PWAhCcKVNqk8jTP48Fmcmf6J+bBd4l/WuLG3/UI7PPNoPAhD2Yf/Hfy802bE4r5/rnZpwZkXA+Dm2m4= X-Received: by 10.202.208.92 with SMTP id h89mr2854245oig.90.1504780341694; Thu, 07 Sep 2017 03:32:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.93.71 with HTTP; Thu, 7 Sep 2017 03:31:41 -0700 (PDT) In-Reply-To: References: From: Tier Nolan Date: Thu, 7 Sep 2017 11:31:41 +0100 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="001a113ca1debb56eb055896f9e2" X-Spam-Status: No, score=0.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,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 Subject: Re: [bitcoin-dev] SF proposal: prohibit unspendable outputs with amount=0 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 10:32:23 -0000 --001a113ca1debb56eb055896f9e2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable You could have a timelocked transaction that has a zero value input (and other non-zero inputs). If the SF happened, that transaction would become unspendable. The keys to the outputs may be lost or the co-signer may refuse to cooperate. There seems to be some objections to long term timelocked transactions. If someone asked me about it, I would recommend that any timelocked transactions should very carefully make sure that they use forms that are popular. I think the fairest rule would be that any change which makes some transactions invalid should be opt-in and only apply to new transaction version numbers. If you create a timelocked transactions with an undefined version number, then you have little to complain about. If the version number is defined and in-use, then transactions should not suddenly lose validity. A refusal to commit to that makes long term locktime use much more risky. On Thu, Sep 7, 2017 at 12:54 AM, CryptAxe via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > As long as an unspendable outputs (OP_RETURN outputs for example) with > amount=3D0 are still allowed I don't see it being an issue for anything. > > On Sep 5, 2017 2:52 PM, "Jorge Tim=C3=B3n via bitcoin-dev" linuxfoundation.org> wrote: > >> This is not a priority, not very important either. >> Right now it is possible to create 0-value outputs that are spendable >> and thus stay in the utxo (potentially forever). Requiring at least 1 >> satoshi per output doesn't really do much against a spam attack to the >> utxo, but I think it would be slightly better than the current >> situation. >> >> Is there any reason or use case to keep allowing spendable outputs >> with null amounts in them? >> >> If not, I'm happy to create a BIP with its code, this should be simple. >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --001a113ca1debb56eb055896f9e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You could have a timelocked transaction that has a ze= ro value input (and other non-zero inputs).=C2=A0 If the SF happened, that = transaction would become unspendable.

The keys to the out= puts may be lost or the co-signer may refuse to cooperate.

There seems to be some objections to long term timelocked transactions.
If someone asked me about it, I would recommend that any t= imelocked transactions should very carefully make sure that they use forms = that are popular.

I think the fairest rule would be that = any change which makes some transactions invalid should be opt-in and only = apply to new transaction version numbers.

If you create a= timelocked transactions with an undefined version number, then you have li= ttle to complain about.=C2=A0

If the version number is defined and = in-use, then transactions should not suddenly lose validity.

<= div>A refusal to commit to that makes long term locktime use much more risk= y.

On Thu, Sep 7, 2017 at 12:54 AM, CryptAxe via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
=
As long as an unspendable = outputs (OP_RETURN outputs for example) with amount=3D0 are still allowed I= don't see it being an issue for anything.=C2=A0

On Sep 5, 2017 2:52 PM, "Jorge Tim=C3=B3n via bitcoin-dev" = <bitcoin-dev@lists.linuxfoundation.org> wrote:
This is not a priority, not very = important either.
Right now it is possible to create 0-value outputs that are spendable
and thus stay in the utxo (potentially forever). Requiring at least 1
satoshi per output doesn't really do much against a spam attack to the<= br> utxo, but I think it would be slightly better than the current
situation.

Is there any reason or use case to keep allowing spendable outputs
with null amounts in them?

If not, I'm happy to create a BIP with its code, this should be simple.=
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev


--001a113ca1debb56eb055896f9e2--