From: "\ Jorge Timón" <jtimonmv@gmail•com>
To: Gavin Andresen <gavinandresen@gmail•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Blocking uneconomical UTXO creation
Date: Mon, 11 Mar 2013 17:45:15 +0100 [thread overview]
Message-ID: <CABOyFfrO9Xpc=Pdh_6AM1yoHRCeuHxzqL02F-ALkimmsGbheiA@mail.gmail.com> (raw)
In-Reply-To: <CABsx9T1rt+7BQHz1S=NVtL_YV7kfCapQ+3MEf+xyXT7pZOfq7w@mail.gmail.com>
"The Bitcoin network will destroy your coins IF you don't move your coins"
Is pretty different. By the way, doesn't have to destroy them, can
just give them to miners.
In any case, what's wrong with my reasoning?
Smart property/colored coins are not spam transactions because they pay fees.
The problem for the network are not transactions that move less coins
than they pay fees, but old UNSPENT OUTPUTS. So why don't you focus on
that instead of a formula to check what transactions make "economic
sense"?
I even prefer the sudden "destruction" (or re-generation by miners) of
the account after the X period (killerstorm's proposal) instead of
just rejecting great potential use cases for the chain.
I mean, I still prefer a small fixed demurrage fee after those X
blocks without moving them, but since this community is demurrage
allergic and that possibility cannot even be considered (doesn't
matter what reflects better the costs for miners/the network I guess),
I'll go with the second best option IMO.
This would be just a fee for a resource that users are enjoying and
has real costs for the network. Why would constant demurrage fees
after a free storage period would be perceived so different from
transaction fees?
I haven't heard anyone complaining about "the bitcoin developers are
destroying part of YOUR coins every time you move them!!"
On 3/11/13, Gavin Andresen <gavinandresen@gmail•com> wrote:
>> Just activate a non-proportional demurrage
>
> demurrage of any kind will never, ever happen, just give up on that idea.
>
> The negative publicity of "the bitcoin developers are destroying YOUR
> coins!" would be devastating.
>
> --
> --
> Gavin Andresen
>
--
Jorge Timón
http://freico.in/
http://archive.ripple-project.org/
next prev parent reply other threads:[~2013-03-11 16:45 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-10 4:31 Peter Todd
2013-03-11 11:01 ` Jorge Timón
2013-03-11 15:36 ` Gavin Andresen
2013-03-11 16:45 ` Jorge Timón [this message]
2013-03-11 16:46 ` Jorge Timón
2013-03-11 16:54 ` Mike Hearn
2013-03-11 17:08 ` Jorge Timón
2013-03-11 18:17 ` Benjamin Lindner
2013-03-11 18:59 ` Mark Friedenbach
2013-03-11 18:59 ` Jorge Timón
2013-03-11 19:08 ` Tadas Varanavičius
2013-03-11 22:19 ` Mike Hearn
2013-03-11 22:25 ` Tadas Varanavičius
2013-03-11 22:39 ` Mike Hearn
2013-03-11 23:26 ` Tadas Varanavičius
2013-03-11 17:18 ` Jeff Garzik
2013-03-11 20:08 ` Rune Kjær Svendsen
2013-03-11 20:36 ` Michael Gronager
2013-03-11 21:01 ` Gregory Maxwell
2013-03-11 21:15 ` Michael Gronager
2013-03-12 7:49 ` Peter Todd
2013-03-13 5:31 ` Stephen Pair
2013-03-13 9:20 ` Jorge Timón
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='CABOyFfrO9Xpc=Pdh_6AM1yoHRCeuHxzqL02F-ALkimmsGbheiA@mail.gmail.com' \
--to=jtimonmv@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gavinandresen@gmail$(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