path: root/76/59d137de7362b89010c6ba1b472fb01df6d7dc

Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <tier.nolan@gmail.com>) id 1Yqjhi-000214-EB
	for bitcoin-development@lists.sourceforge.net;
	Fri, 08 May 2015 14:56:42 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.220.174 as permitted sender)
	client-ip=209.85.220.174; envelope-from=tier.nolan@gmail.com;
	helo=mail-qk0-f174.google.com; 
Received: from mail-qk0-f174.google.com ([209.85.220.174])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Yqjhh-0007O4-Aw
	for bitcoin-development@lists.sourceforge.net;
	Fri, 08 May 2015 14:56:42 +0000
Received: by qku63 with SMTP id 63so49527669qku.3
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 08 May 2015 07:56:36 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.229.16.69 with SMTP id n5mr5634020qca.25.1431096995945; Fri,
	08 May 2015 07:56:35 -0700 (PDT)
Received: by 10.140.85.241 with HTTP; Fri, 8 May 2015 07:56:35 -0700 (PDT)
In-Reply-To: <CAOoPuRZo6M1-XTYk6LebADHwQVwKEOYtaHGvEoRkk5AfevvJYw@mail.gmail.com>
References: <CAE-z3OUiK_s-gJtnPquUZbG5aJkJjfo+VYKHgX+Bfcgem+6i9A@mail.gmail.com>
	<CANEZrP2OXSmhLsfvpsQdr0QGbGyJWaAp1F0itu4V_C-E+0gO6A@mail.gmail.com>
	<CAOoPuRZG4CVxcgExKHjDQd+F-w6xr6cJZD7pShbgPJd9CnqTwg@mail.gmail.com>
	<CAE-z3OV30-ds5=5Tm55n+B26sPz3P+iC2TNHTBUidbX=qu08nQ@mail.gmail.com>
	<CAOoPuRZo6M1-XTYk6LebADHwQVwKEOYtaHGvEoRkk5AfevvJYw@mail.gmail.com>
Date: Fri, 8 May 2015 15:56:35 +0100
Message-ID: <CAE-z3OUypPwtvzhFJEPYfO7zw4NxmEEXNtRFfqQrVCO2Z2jr6A@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a1133e3f61529310515933c59
X-Spam-Score: 1.5 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(tier.nolan[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.2 MISSING_HEADERS        Missing To: header
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
	1.6 MALFORMED_FREEMAIL Bad headers on message from free email service
	-0.7 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1Yqjhh-0007O4-Aw
Subject: Re: [Bitcoin-development] Assurance contracts to fund the network
 with OP_CHECKLOCKTIMEVERIFY
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 08 May 2015 14:56:42 -0000

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

On Fri, May 8, 2015 at 3:54 PM, Benjamin <benjamin.l.cordes@gmail.com>
wrote:

> AC does not solve the problem. AC works if people gain directly from
> the payment.


Not necessarily.









> Imagine a group of people paying tax - nobody gains from
> paying it. You have to actually need to enforce negative outcomes to
> enable it (jail for tax fraud). Hence in Bitcoin we have the enforced
> subsidy. AFAIK the problem of how to incentivize transaction
> verification without subsidy is unsolved. Who determines a fair price?
> People around here should study more economics, game theory, etc.
> instead of debating low level encodings all the time.
>
> On Fri, May 8, 2015 at 4:15 PM, Tier Nolan <tier.nolan@gmail.com> wrote:
> > Just to clarify the process.
> >
> > Pledgers create transactions using the following template and broadcast
> > them.  The p2p protocol could be modified to allow this, or it could be a
> > separate system.
> >
> > Input: 0.01 BTC
> > Signed with SIGHASH_ANYONE_CAN_PAY
> >
> > Output 50BTC
> > Paid to: <1 million> OP_CHECKLOCKTIMEVERIFY OP_TRUE
> >
> > Output 0.01BTC
> > Paid to OP_TRUE
> >
> > This transaction is invalid, since the inputs don't pay for the output.
> The
> > advantage of the sighash "anyone can pay" field is that other people can
> add
> > additional inputs without making the signature invalid.  Normally, any
> > change to the transaction would make a signature invalid.
> >
> > Eventually, enough other users have added pledges and a valid transaction
> > can be broadcast.
> >
> > Input: 0.01 BTC
> > Signed with SIGHASH_ANYONE_CAN_PAY
> >
> > Input: 1.2 BTC
> > Signed with SIGHASH_ANYONE_CAN_PAY
> >
> > Input: 5 BTC
> > Signed with SIGHASH_ANYONE_CAN_PAY
> >
> > <etc>
> >
> > Input: 1.3 BTC
> > Signed with SIGHASH_ANYONE_CAN_PAY
> >
> > Output 50BTC
> > Paid to: <1 million> OP_CHECKLOCKTIMEVERIFY OP_TRUE
> >
> > Output 0.01BTC
> > Paid to OP_TRUE
> >
> > This transaction can be submitted to the main network.  Once it is
> included
> > into the blockchain, it is locked in.
> >
> > In this example, it might be included in block 999,500.  The 0.01BTC
> output
> > (and any excess over 50BTC) can be collected by the block 999,500 miner.
> >
> > The OP_CHECKLOCKTIMEVERIFY opcode means that the 50BTC output cannot be
> > spent until block 1 million.  Once block 1 million arrives, the output is
> > completely unprotected.  This means that the miner who mines block 1
> million
> > can simply take it, by including his own transaction that sends it to an
> > address he controls.  It would be irrational to include somebody else's
> > transaction which spent it.
> >
> > If by block 999,900, the transaction hasn't been completed (due to not
> > enough pledgers), the pledgers can spend the coin(s) that they were
> going to
> > use for their pledge.  This invalidates those inputs and effectively
> > withdraws from the pledge.
> >
> > On Fri, May 8, 2015 at 11:01 AM, Benjamin <benjamin.l.cordes@gmail.com>
> > wrote:
> >>
> >> 2. "A merchant wants to cause block number 1 million to effectively
> >> have a minting fee of 50BTC." - why should he do that? That's the
> >> entire tragedy of the commons problem, no?
> >
> >
> > No, the pledger is saying that he will only pay 0.01BTC if the miner
> gets a
> > reward of 50BTC.
> >
> > Imagine a group of 1000 people who want to make a donation of 50BTC to
> > something.  They all way that they will donate 0.05BTC, but only if
> everyone
> > else donates.
> >
> > It still isn't perfect.  Everyone has an incentive to wait until the last
> > minute to pledge.
>

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Fri, May 8, 2015 at 3:54 PM, Benjamin <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:benjamin.l.cordes@gmail.com" target=3D"_blank">benjamin.l.cordes@gmai=
l.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=
=3D"">
</span>AC does not solve the problem. AC works if people gain directly from=
<br>
the payment.</blockquote><div><br></div><div>Not necessarily.<br><br><br></=
div><div><br></div><div><br><br><br></div><div><br>=C2=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"> Imagine a group of people paying tax - nobody gains fro=
m<br>
paying it. You have to actually need to enforce negative outcomes to<br>
enable it (jail for tax fraud). Hence in Bitcoin we have the enforced<br>
subsidy. AFAIK the problem of how to incentivize transaction<br>
verification without subsidy is unsolved. Who determines a fair price?<br>
People around here should study more economics, game theory, etc.<br>
instead of debating low level encodings all the time.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
On Fri, May 8, 2015 at 4:15 PM, Tier Nolan &lt;<a href=3D"mailto:tier.nolan=
@gmail.com">tier.nolan@gmail.com</a>&gt; wrote:<br>
&gt; Just to clarify the process.<br>
&gt;<br>
&gt; Pledgers create transactions using the following template and broadcas=
t<br>
&gt; them.=C2=A0 The p2p protocol could be modified to allow this, or it co=
uld be a<br>
&gt; separate system.<br>
&gt;<br>
&gt; Input: 0.01 BTC<br>
&gt; Signed with SIGHASH_ANYONE_CAN_PAY<br>
&gt;<br>
&gt; Output 50BTC<br>
&gt; Paid to: &lt;1 million&gt; OP_CHECKLOCKTIMEVERIFY OP_TRUE<br>
&gt;<br>
&gt; Output 0.01BTC<br>
&gt; Paid to OP_TRUE<br>
&gt;<br>
&gt; This transaction is invalid, since the inputs don&#39;t pay for the ou=
tput.=C2=A0 The<br>
&gt; advantage of the sighash &quot;anyone can pay&quot; field is that othe=
r people can add<br>
&gt; additional inputs without making the signature invalid.=C2=A0 Normally=
, any<br>
&gt; change to the transaction would make a signature invalid.<br>
&gt;<br>
&gt; Eventually, enough other users have added pledges and a valid transact=
ion<br>
&gt; can be broadcast.<br>
&gt;<br>
&gt; Input: 0.01 BTC<br>
&gt; Signed with SIGHASH_ANYONE_CAN_PAY<br>
&gt;<br>
&gt; Input: 1.2 BTC<br>
&gt; Signed with SIGHASH_ANYONE_CAN_PAY<br>
&gt;<br>
&gt; Input: 5 BTC<br>
&gt; Signed with SIGHASH_ANYONE_CAN_PAY<br>
&gt;<br>
&gt; &lt;etc&gt;<br>
&gt;<br>
&gt; Input: 1.3 BTC<br>
&gt; Signed with SIGHASH_ANYONE_CAN_PAY<br>
&gt;<br>
&gt; Output 50BTC<br>
&gt; Paid to: &lt;1 million&gt; OP_CHECKLOCKTIMEVERIFY OP_TRUE<br>
&gt;<br>
&gt; Output 0.01BTC<br>
&gt; Paid to OP_TRUE<br>
&gt;<br>
&gt; This transaction can be submitted to the main network.=C2=A0 Once it i=
s included<br>
&gt; into the blockchain, it is locked in.<br>
&gt;<br>
&gt; In this example, it might be included in block 999,500.=C2=A0 The 0.01=
BTC output<br>
&gt; (and any excess over 50BTC) can be collected by the block 999,500 mine=
r.<br>
&gt;<br>
&gt; The OP_CHECKLOCKTIMEVERIFY opcode means that the 50BTC output cannot b=
e<br>
&gt; spent until block 1 million.=C2=A0 Once block 1 million arrives, the o=
utput is<br>
&gt; completely unprotected.=C2=A0 This means that the miner who mines bloc=
k 1 million<br>
&gt; can simply take it, by including his own transaction that sends it to =
an<br>
&gt; address he controls.=C2=A0 It would be irrational to include somebody =
else&#39;s<br>
&gt; transaction which spent it.<br>
&gt;<br>
&gt; If by block 999,900, the transaction hasn&#39;t been completed (due to=
 not<br>
&gt; enough pledgers), the pledgers can spend the coin(s) that they were go=
ing to<br>
&gt; use for their pledge.=C2=A0 This invalidates those inputs and effectiv=
ely<br>
&gt; withdraws from the pledge.<br>
&gt;<br>
&gt; On Fri, May 8, 2015 at 11:01 AM, Benjamin &lt;<a href=3D"mailto:benjam=
in.l.cordes@gmail.com">benjamin.l.cordes@gmail.com</a>&gt;<br>
&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; 2. &quot;A merchant wants to cause block number 1 million to effec=
tively<br>
&gt;&gt; have a minting fee of 50BTC.&quot; - why should he do that? That&#=
39;s the<br>
&gt;&gt; entire tragedy of the commons problem, no?<br>
&gt;<br>
&gt;<br>
&gt; No, the pledger is saying that he will only pay 0.01BTC if the miner g=
ets a<br>
&gt; reward of 50BTC.<br>
&gt;<br>
&gt; Imagine a group of 1000 people who want to make a donation of 50BTC to=
<br>
&gt; something.=C2=A0 They all way that they will donate 0.05BTC, but only =
if everyone<br>
&gt; else donates.<br>
&gt;<br>
&gt; It still isn&#39;t perfect.=C2=A0 Everyone has an incentive to wait un=
til the last<br>
&gt; minute to pledge.<br>
</div></div></blockquote></div><br></div></div>

--001a1133e3f61529310515933c59--