From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 8F3648D7 for ; Mon, 2 Nov 2015 01:30:52 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F1043150 for ; Mon, 2 Nov 2015 01:30:51 +0000 (UTC) Received: by qgeo38 with SMTP id o38so106386739qge.0 for ; Sun, 01 Nov 2015 17:30:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=6UtFUFitHim62nlOG7D370B9dDLGC8ET7Du4Rtk4130=; b=rB2p9eBEYgWyCnCR+mYCLqYmQJqAPQuunbpBy8Bbt48nEMEMePwoQfmvsSohpkCFyn UVSxe3SF+W7prX/tzK3+j3/UmYI+CmlOWzpZNmb5WQXrRdy2FIyOZJqd53DhFNg8qDiu F60QI8+bn7P4oKi2C8fcHfIZGB2ePDFJ46xwAKRRAYQQxPMpHvrelVDAj99r1MKkE1FB 0KiNgDD4i5sadDrvcWVnOkfRUTtexncvsLG6qFw/epLtbgDL03BpkVGCZ7egNo9e04nE e2GGp1uRpFy15CAvJYB4TECWQtPVCmyzzEN9gpKubTRcguGvjXvz8VJW3SLL/mgaYwWk CgXA== MIME-Version: 1.0 X-Received: by 10.140.181.197 with SMTP id c188mr11491753qha.4.1446427851149; Sun, 01 Nov 2015 17:30:51 -0800 (PST) Received: by 10.140.30.201 with HTTP; Sun, 1 Nov 2015 17:30:51 -0800 (PST) In-Reply-To: <5636ACFF.5040908@openbitcoinprivacyproject.org> References: <5636ACFF.5040908@openbitcoinprivacyproject.org> Date: Mon, 2 Nov 2015 01:30:51 +0000 Message-ID: From: Tier Nolan Cc: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a113a95be43058e052384ba20 X-Spam-Status: No, score=1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, MALFORMED_FREEMAIL, MISSING_HEADERS,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Compatibility requirements for hard or soft forks X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 01:30:52 -0000 --001a113a95be43058e052384ba20 Content-Type: text/plain; charset=UTF-8 On Mon, Nov 2, 2015 at 12:23 AM, Justus Ranvier via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Are there actually any OP_CAT scripts currently in the utxo set? > A locked transaction could pay to an OP_CAT script with the private key being lost. Even if it is only in theory, it is still worth trying to prevent rule changes which permanently prevent outputs being spendable. > It's a lot easier to justify the position: "nobody has the right to > change the meaning of someone else's outputs", than it is to justify, > "some small group of people gets to decide what's standard and what > isn't, and if you choose to use the network in a valid but nonstandard > way, that group of people might choose to deny you access to your money > in the future" > If at least one year's notice was given, then people aren't going to lose their money, since they have notice. Locked transactions could have a difference expectation than non-locked ones. > In other words, how close to the shores of "administrators of a virtual > currency" do Bitcoin developers want to sail? > Miners can collectively vote to disable specific UTXOs and change the acceptance rules. > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --001a113a95be43058e052384ba20 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Nov 2, 2015 at 12:23 AM, Justus Ranvier via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:<= br>
Are there actually any OP_CAT scripts currently in the utxo set?
=

A locked transaction could pay to an OP_CA= T script with the private key being lost.

Even if it is o= nly in theory, it is still worth trying to prevent rule=20 changes which permanently prevent outputs being spendable.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> It's a lot easier to justify the position: "nobody has the right t= o
change the meaning of someone else's outputs", than it is to justi= fy,
"some small group of people gets to decide what's standard and wha= t
isn't, and if you choose to use the network in a valid but nonstandard<= br> way, that group of people might choose to deny you access to your money
in the future"

If at least one yea= r's notice was given, then people aren't going to lose their money,= since they have notice.

Locked transactions could have a= difference expectation than non-locked ones.
=C2=A0
In other words, how close to the shores of "administrators of a virtua= l
currency" do Bitcoin developers want to sail?
Miners can collectively vote to disable specific UTXOs and chan= ge the acceptance rules.




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


--001a113a95be43058e052384ba20--