From: "\ Jorge Timón" <jtimonmv@gmail•com>
To: Benjamin Lindner <ben@benlabs•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Blocking uneconomical UTXO creation
Date: Mon, 11 Mar 2013 19:59:32 +0100 [thread overview]
Message-ID: <CABOyFfqqtU-M4tQv7cvNjGTC83NH6Gwds8gjDmF+GBM==+dLew@mail.gmail.com> (raw)
In-Reply-To: <75F78378-7580-4D69-A5EA-E943AF7CEB0C@benlabs.net>
That solution seems good enough to me.
Smartcoin users would just need to move their assets before 10 years,
totally acceptable.
And regular users don't need to think about it since they're probably
always sending more than they pay in fees.
On 3/11/13, Benjamin Lindner <ben@benlabs•net> wrote:
>
> On Mar 11, 2013, at 12:54 PM, Mike Hearn <mike@plan99•net> wrote:
>> With regards to trying to minimize the size of the UTXO set, this
>> again feels like a solution in search of a problem. Even with SD
>> abusing micropayments as messages, it's only a few hundred megabytes
>> today. That fits in RAM, let alone disk. If one day people do get
>
> The problem of UTXO in principal scales with the block size limit. Thus it
> should be fixed BEFORE you consider increasing the block size limit.
> Otherwise you just kick the can down the road, making it bigger.
>
>> concerned about the working set size, miners can independently set
>> their own policies for what they confirm, for instance maybe they just
>
> Problem is the skewed incentive structure. Rational miners will always
> include dust output with fees, because the eternal cost of UTXO is payed by
> the network and future miners, not the current/individual miner.
>
> On Mar 11, 2013, at 7:01 AM, Jorge Timón <jtimonmv@gmail•com> wrote:
>
>> On 3/10/13, Peter Todd <pete@petertodd•org> wrote:
>>> It's also been suggested multiple times to make transaction outputs with
>>> a value less than the transaction fee non-standard, either with a fixed
>>> constant or by some sort of measurement.
>>
>> As said on the bitcointalk thread, I think this is the wrong approach.
>> This way you effectively disable legitimate use cases for payments
>> that "are worth" less than the fees like smart property/colored coins.
>
> this.
>
>> Just activate a non-proportional
>> demurrage (well, I won't complain if you just turn bitcoin into
>> freicoin, just think that non-proportional would be more acceptable by
>> most bitcoiners) that incentives old transactions to be moved
>
> You could delegate the decision to the user with a rule like:
>
> if (output<fee):
> limit lifetime of the UTXO to 10 years.
> if (output>fee):
> unlimited lifetime
>
> Then, when a user creates a transaction, he can decide whether he wants to
> have limited or unlimited lifetime. The rationale for limiting the lifetime
> for (output<fee) transactions is that they may have no inherent economic
> incentive to be spend.
>
>
> ------------------------------------------------------------------------------
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
> endpoint security space. For insight on selecting the right partner to
> tackle endpoint security challenges, access the full report.
> http://p.sf.net/sfu/symantec-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Jorge Timón
http://freico.in/
http://archive.ripple-project.org/
next prev parent reply other threads:[~2013-03-11 18:59 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
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 [this message]
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='CABOyFfqqtU-M4tQv7cvNjGTC83NH6Gwds8gjDmF+GBM==+dLew@mail.gmail.com' \
--to=jtimonmv@gmail$(echo .)com \
--cc=ben@benlabs$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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