From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: References: Date: Fri, 8 May 2015 15:56:35 +0100 Message-ID: From: Tier Nolan Cc: Bitcoin Dev 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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 > > > > > > > > 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 > > 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

= On Fri, May 8, 2015 at 3:54 PM, Benjamin <benjamin.l.cordes@gmai= l.com> wrote:
AC does not solve the problem. AC works if people gain directly from=
the payment.

Not necessarily.







=C2=A0
Imagine a group of people paying tax - nobody gains fro= m
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 broadcas= t
> them.=C2=A0 The p2p protocol could be modified to allow this, or it co= uld 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 ou= tput.=C2=A0 The
> advantage of the sighash "anyone can pay" field is that othe= r people can add
> additional inputs without making the signature invalid.=C2=A0 Normally= , any
> change to the transaction would make a signature invalid.
>
> Eventually, enough other users have added pledges and a valid transact= ion
> 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.=C2=A0 Once it i= s included
> into the blockchain, it is locked in.
>
> In this example, it might be included in block 999,500.=C2=A0 The 0.01= BTC output
> (and any excess over 50BTC) can be collected by the block 999,500 mine= r.
>
> The OP_CHECKLOCKTIMEVERIFY opcode means that the 50BTC output cannot b= e
> spent until block 1 million.=C2=A0 Once block 1 million arrives, the o= utput is
> completely unprotected.=C2=A0 This means that the miner who mines bloc= k 1 million
> can simply take it, by including his own transaction that sends it to = an
> address he controls.=C2=A0 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 go= ing to
> use for their pledge.=C2=A0 This invalidates those inputs and effectiv= ely
> 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 effec= tively
>> have a minting fee of 50BTC." - why should he do that? That&#= 39;s the
>> entire tragedy of the commons problem, no?
>
>
> No, the pledger is saying that he will only pay 0.01BTC if the miner g= ets a
> reward of 50BTC.
>
> Imagine a group of 1000 people who want to make a donation of 50BTC to=
> something.=C2=A0 They all way that they will donate 0.05BTC, but only = if everyone
> else donates.
>
> It still isn't perfect.=C2=A0 Everyone has an incentive to wait un= til the last
> minute to pledge.

--001a1133e3f61529310515933c59--