From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Yxv5b-0001X8-E3 for bitcoin-development@lists.sourceforge.net; Thu, 28 May 2015 10:31:03 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.49 as permitted sender) client-ip=74.125.82.49; envelope-from=mh.in.england@gmail.com; helo=mail-wg0-f49.google.com; Received: from mail-wg0-f49.google.com ([74.125.82.49]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Yxv5Z-0000cf-Tr for bitcoin-development@lists.sourceforge.net; Thu, 28 May 2015 10:31:03 +0000 Received: by wgbgq6 with SMTP id gq6so32383624wgb.3 for ; Thu, 28 May 2015 03:30:56 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.61.82 with SMTP id n18mr3800637wjr.35.1432809055947; Thu, 28 May 2015 03:30:55 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.194.143.9 with HTTP; Thu, 28 May 2015 03:30:55 -0700 (PDT) In-Reply-To: References: <5550D8BE.6070207@electrum.org> Date: Thu, 28 May 2015 12:30:55 +0200 X-Google-Sender-Auth: 8I6nX2Dz4z-d03apEg45CZDAh_4 Message-ID: From: Mike Hearn To: Gregory Maxwell Content-Type: multipart/alternative; boundary=047d7ba97780cf9351051721daff X-Spam-Score: -0.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 (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 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 X-Headers-End: 1Yxv5Z-0000cf-Tr Cc: Bitcoin Development Subject: Re: [Bitcoin-development] Long-term mining incentives 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: Thu, 28 May 2015 10:31:03 -0000 --047d7ba97780cf9351051721daff Content-Type: text/plain; charset=UTF-8 > > The prior (and seemingly this) assurance contract proposals pay the > miners who mines a chain supportive of your interests and miners whom > mine against your interests identically. > The same is true today - via inflation I pay for blocks regardless of whether they contain or double spend my transactions or not. So I don't see why it'd be different in future. > There is already a mechanism built into Bitcoin for paying for > security which doesn't have this problem, and which mitigates the > common action problem of people just sitting around for other people > to pay for security: transaction fees. The article states quite clearly that assurance contracts are proposed only if people setting transaction fees themselves doesn't work. There's some reasonably good arguments that it probably won't work, but I don't assign very high weight to game theoretic arguments these days so it wouldn't surprise me if Satoshi's original plan worked out OK too. Of course, by the time this matters I plan to be sipping a pina colada on my private retirement beach :) It's a problem the next generation can tackle, as far as I am concerned. > Considering the near-failure in just keeping development funded, I'm not > sure where the believe this this model will be workable comes from Patience :) Right now it's a lot easier to get development money from VC funds and rich benefactors than raising it directly from the community, so unsurprisingly that's what most people do. Despite that, the Hourglass design document project now has sufficient pre-pledges that it should be possible to crowdfund it successfully once I get around to actually doing the work. And BitSquare was able to raise nearly half of their target despite an incredibly aggressive deadline and the fact that they hadn't shipped a usable prototype. I think as people get better at crafting their contracts and people get more experience with funding work this way, we'll see it get more common. But yes. Paying for things via assurance contracts is a long term and very experimental plan, for sure. > one time cost. I note that many existing crowdfunding platforms > (including your own) do not do ongoing costs with this kind of binary > contract. > Lighthouse wasn't written to do hashing assurance contracts, so no, it doesn't have such a feature. Perhaps in version 2. --047d7ba97780cf9351051721daff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The prior (and seemingly this) assurance contrac= t proposals pay the
miners who mines a chain supportive of your interests and miners whom
mine against your interests identically.

The same is true today - via inflation I pay for blocks regardless of whe= ther they contain or double spend my transactions or not. So I don't se= e why it'd be different in future.
=C2=A0
There is already a mechanism built into Bitcoin for paying= for
security which doesn't have this problem, and which mitigates the
common action problem of people just sitting around for other people
to pay for security: transaction fees.

The= article states quite clearly that assurance contracts are proposed only if= people setting transaction fees themselves doesn't work. There's s= ome reasonably good arguments that it probably won't work, but I don= 9;t assign very high weight to game theoretic arguments these days so it wo= uldn't surprise me if Satoshi's original plan worked out OK too.

Of course, by the time this matters I plan to be sip= ping a pina colada on my private retirement beach :) It's a problem the= next generation can tackle, as far as I am concerned.
=C2=A0
Considering the near-failure in just=C2=A0= keeping development funded, I'm not sure where the believe this this=C2= =A0model will be workable comes from

Patien= ce :)=C2=A0

Right now it's a lot easier to get= development money from VC funds and rich benefactors than raising it direc= tly from the community, so unsurprisingly that's what most people do.= =C2=A0

Despite that, the Hourglass design document= project now has sufficient pre-pledges that it should be possible to crowd= fund it successfully once I get around to actually doing the work. And BitS= quare was able to raise nearly half of their target despite an incredibly a= ggressive deadline and the fact that they hadn't shipped a usable proto= type. I think as people get better at crafting their contracts and people g= et more experience with funding work this way, we'll see it get more co= mmon.

But yes. Paying for things via assurance con= tracts is a long term and very experimental plan, for sure.
=C2= =A0
one time cost. I note that many exi= sting crowdfunding platforms
(including your own) do not do ongoing costs with this kind of binary
contract.

Lighthouse wasn't written= to do hashing assurance contracts, so no, it doesn't have such a featu= re. Perhaps in version 2.

--047d7ba97780cf9351051721daff--