From: Pieter Wuille <pieter.wuille@gmail•com>
To: Michael Gronager <gronager@ceptacle•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
Date: Mon, 3 Dec 2012 13:33:09 +0100 [thread overview]
Message-ID: <CAPg+sBhwUz4ddEXRT0p7mQUwHkqtTes1i88a-uqsa+QQs2n=CA@mail.gmail.com> (raw)
In-Reply-To: <9CEDE4D4-3685-4F70-953E-15CC50A8AA3F@ceptacle.com>
[-- Attachment #1: Type: text/plain, Size: 1543 bytes --]
On Mon, Dec 3, 2012 at 1:24 PM, Michael Gronager <gronager@ceptacle•com>wrote:
> > If this were a proposal at the time Bitcoin was created, I would
> definitely be in favor, but I feel we can't just change such a policy right
> now - it's not what people signed up for when they started using the
> system. I also see no way to implement this without a hard fork, which
> would require planning at least 1-2 years in advance (imho). By that time,
> the economic landscape of Bitcoin may be vastly different, and either dust
> spam will have killed it, or we will have found another solution already.
>
> Bitcoin aka the blockchain is defined by the majority of the miners. This
> is what people have signed up to imo. A scheme that a) is of benefit for us
> all and b) is also of economical benefit for the miners, will likely be
> accepted quite fast - especially now when the bounty was just halved... I
> also fear that there is a lot of BTCs that is effectively un-owned and it
> could even drive Satoshi to use some of his BTCs ;)
I disagree completely. The only power granted to miners is to decide the
order of otherwise valid transactions (up to postponing some indefinitely)
- they have no ability to control the rules for validity them self In
particular, the rules that prevent double spending and (monetary) inflation
of the currency are deliberately NOT left to miners. If this were the case,
they could just as well vote to keep the 50 BTC block payout, and that
would certainly not be what people signed up for.
--
Pieter
[-- Attachment #2: Type: text/html, Size: 1908 bytes --]
next prev parent reply other threads:[~2012-12-03 12:33 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-03 11:19 Michael Gronager
2012-12-03 12:05 ` Pieter Wuille
2012-12-03 12:24 ` Michael Gronager
2012-12-03 12:33 ` Pieter Wuille [this message]
2012-12-03 15:02 ` Gregory Maxwell
2012-12-03 15:17 ` Alan Reiner
2012-12-03 15:30 ` Mike Hearn
2012-12-03 16:18 ` Stephen Pair
2012-12-03 16:29 ` Alan Reiner
2012-12-03 19:50 ` Andreas Petersson
2012-12-03 20:14 ` Gregory Maxwell
2012-12-03 15:51 ` Gregory Maxwell
2012-12-03 12:40 ` Wladimir
2012-12-03 13:04 ` Michael Gronager
2012-12-03 15:00 ` Mike Hearn
2012-12-03 15:07 ` Gregory Maxwell
2012-12-03 15:09 ` Mike Hearn
2012-12-03 17:02 ` Mark Friedenbach
2012-12-04 9:54 ` Andy Parkins
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='CAPg+sBhwUz4ddEXRT0p7mQUwHkqtTes1i88a-uqsa+QQs2n=CA@mail.gmail.com' \
--to=pieter.wuille@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gronager@ceptacle$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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