From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UF91S-0001qd-Ls for bitcoin-development@lists.sourceforge.net; Mon, 11 Mar 2013 20:08:38 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.54 as permitted sender) client-ip=74.125.82.54; envelope-from=runesvend@gmail.com; helo=mail-wg0-f54.google.com; Received: from mail-wg0-f54.google.com ([74.125.82.54]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UF91Q-0005nl-OU for bitcoin-development@lists.sourceforge.net; Mon, 11 Mar 2013 20:08:38 +0000 Received: by mail-wg0-f54.google.com with SMTP id fm10so5248256wgb.21 for ; Mon, 11 Mar 2013 13:08:30 -0700 (PDT) X-Received: by 10.180.98.232 with SMTP id el8mr15276019wib.22.1363032510412; Mon, 11 Mar 2013 13:08:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.44.132 with HTTP; Mon, 11 Mar 2013 13:08:10 -0700 (PDT) In-Reply-To: References: <20130310043155.GA20020@savin> From: =?ISO-8859-1?Q?Rune_Kj=E6r_Svendsen?= Date: Mon, 11 Mar 2013 21:08:10 +0100 Message-ID: To: bitcoin-development@lists.sourceforge.net Content-Type: multipart/alternative; boundary=f46d0442885e99bfa804d7abbcc0 X-Spam-Score: -0.6 (/) 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 (runesvend[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 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: 1UF91Q-0005nl-OU Subject: Re: [Bitcoin-development] Blocking uneconomical UTXO creation 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: Mon, 11 Mar 2013 20:08:38 -0000 --f46d0442885e99bfa804d7abbcc0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Mar 11, 2013 at 12:01 PM, Jorge Tim=F3n wrote: > On 3/10/13, Peter Todd wrote: > > It's also been suggested multiple times to make transaction outputs wit= h > > 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. > While the transactions pay fees, they should not be considered spam > regardless of how little the quantities being moved are. > > Then your only concern are unspent outputs and comparing fees with > values doesn't help in any way. > 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 and > destroys unspent transactions with small amounts that don't move to > another address periodically. This has been proposed many times before > too, and I think it makes a lot more sense. > >From an economic point of view this *does* make sense, in my opinion. Storing an unspent transaction in the block chain costs money because we can't prune it. However, it would completely destroy confidence in Bitcoin, as far as I can see. It makes sense economically, but it isn't feasible if we want to maintain people's confidence in Bitcoin. I like Jeff's proposal of letting an alt-coin implement this. If it gets to the point where Bitcoin can't function without this functionality, it'll be a lot easier to make the transition, instead of now, when it's not really needed, and the trust in Bitcoin really isn't that great. /Rune > > > -------------------------------------------------------------------------= ----- > 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 > --f46d0442885e99bfa804d7abbcc0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Mar 11, 2013 at 12:01 PM, Jorge Tim=F3n <jtimon= mv@gmail.com> wrote:
On 3/10/13, Peter Todd <= ;pete@petertodd.org> wrote: > It's also been suggested multiple times to make transaction output= s with
> a value less than the transaction fee non-standard, either with a fixe= d
> 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 c= oins.
While the transactions pay fees, they should not be considered spam
regardless of how little the quantities being moved are.

Then your only concern are unspent outputs and comparing fees with
values doesn't help in any way.

=A0
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 and
destroys unspent transactions with small amounts that don't move to
another address periodically. This has been proposed many times before
too, and I think it makes a lot more sense.

=
From an economic point of view this *does* make sense, in my opi= nion. Storing an unspent transaction in the block chain costs money because= we can't prune it. However, it would completely destroy confidence in = Bitcoin, as far as I can see. It makes sense economically, but it =A0isn= 9;t feasible if we want to maintain people's confidence in Bitcoin.

I like Jeff's proposal of letting an al= t-coin implement this. If it gets to the point where Bitcoin can't func= tion without this functionality, it'll be a lot easier to make the tran= sition, instead of now, when it's not really needed, and the trust in B= itcoin really isn't that great.

/Rune

=A0

---------------------------------------------------------------------------= ---
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-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--f46d0442885e99bfa804d7abbcc0--