public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Mike Hearn <mike@plan99.net>
To: Gregory Maxwell <gmaxwell@gmail.com>
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Long-term mining incentives
Date: Thu, 28 May 2015 12:30:55 +0200	[thread overview]
Message-ID: <CANEZrP0toD-oJZRL62GN=TOVeG=dfd8k3MNh54mvkdteETA4XA@mail.gmail.com> (raw)
In-Reply-To: <CAAS2fgTdt9zY8KeOaob+idse1j9eraazBo5HukxJ8nkC_h=Zfw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2363 bytes --]

>
> 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.

[-- Attachment #2: Type: text/html, Size: 3230 bytes --]

  reply	other threads:[~2015-05-28 10:31 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-11 16:28 [Bitcoin-development] Long-term mining incentives Thomas Voegtlin
2015-05-11 16:52 ` insecurity
2015-05-11 17:29   ` Gavin Andresen
2015-05-12 12:35     ` Thomas Voegtlin
     [not found]       ` <CABsx9T1h7p3hDr7ty43uxsYs-oNRpndzg=dowST2tXtogxRm2g@mail.gmail.com>
     [not found]         ` <555210AF.3090705@electrum.org>
2015-05-12 16:10           ` Gavin Andresen
2015-05-12 16:21             ` Dave Hudson
2015-05-12 21:24             ` Pedro Worcel
2015-05-12 23:48               ` Adam Back
2015-05-13 15:41                 ` Gavin Andresen
2015-05-13 20:05                   ` Pedro Worcel
2015-05-13  9:49             ` Thomas Voegtlin
2015-05-13 10:14               ` Tier Nolan
2015-05-13 10:31                 ` Alex Mizrahi
2015-05-13 11:29                   ` Tier Nolan
2015-05-13 12:26                     ` Alex Mizrahi
2015-05-13 13:24                       ` Gavin
2015-05-13 13:28                       ` Tier Nolan
2015-05-13 14:26                         ` Alex Mizrahi
2015-05-13 23:46                   ` Jorge Timón
2015-05-14  0:11     ` Jorge Timón
2015-05-14  0:48       ` Aaron Voisine
2015-05-14  0:58         ` Pieter Wuille
2015-05-14  1:13           ` Aaron Voisine
2015-05-14  1:19             ` Pieter Wuille
2015-05-14  1:31               ` Aaron Voisine
2015-05-14  2:34                 ` Aaron Voisine
2015-05-16 20:35                 ` Owen Gunden
2015-05-16 22:18                   ` Tom Harding
2015-05-17  1:08                   ` Aaron Voisine
2015-05-14  0:44 ` Melvin Carvalho
2015-05-25 18:31 ` Mike Hearn
2015-05-26 18:47   ` Thomas Voegtlin
2015-05-27 21:59   ` Mike Hearn
2015-05-27 22:22     ` Gregory Maxwell
2015-05-28 10:30       ` Mike Hearn [this message]
2015-05-13 17:49 Damian Gomez
2015-05-18  2:29 Michael Jensen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CANEZrP0toD-oJZRL62GN=TOVeG=dfd8k3MNh54mvkdteETA4XA@mail.gmail.com' \
    --to=mike@plan99.net \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=gmaxwell@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox