diff options
| author | Michael Gronager <gronager@ceptacle.com> | 2012-12-03 14:04:22 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2012-12-03 13:04:35 +0000 |
| commit | dd70a845d841d2ccbaa4c93f9dfc01cfb1d5f691 (patch) | |
| tree | 57d3531f8798aaf09b3f878c64b28b95c00e9686 | |
| parent | 96ed3f2d95d7180a658dff90657166119c38d8a1 (diff) | |
| download | pi-bitcoindev-dd70a845d841d2ccbaa4c93f9dfc01cfb1d5f691.tar.gz pi-bitcoindev-dd70a845d841d2ccbaa4c93f9dfc01cfb1d5f691.zip | |
Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
| -rw-r--r-- | 69/0f0ccc81f1e6ad2e6f7ffc22f7218c4da06133 | 88 |
1 files changed, 88 insertions, 0 deletions
diff --git a/69/0f0ccc81f1e6ad2e6f7ffc22f7218c4da06133 b/69/0f0ccc81f1e6ad2e6f7ffc22f7218c4da06133 new file mode 100644 index 000000000..9ae11ec57 --- /dev/null +++ b/69/0f0ccc81f1e6ad2e6f7ffc22f7218c4da06133 @@ -0,0 +1,88 @@ +Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] + helo=mx.sourceforge.net) + by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <gronager@ceptacle.com>) id 1TfVhL-0003AR-6u + for bitcoin-development@lists.sourceforge.net; + Mon, 03 Dec 2012 13:04:35 +0000 +X-ACL-Warn: +Received: from 2508ds5-oebr.1.fullrate.dk ([90.184.5.129] + helo=mail.ceptacle.com) + by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) + id 1TfVhF-0003Gp-Tq for bitcoin-development@lists.sourceforge.net; + Mon, 03 Dec 2012 13:04:35 +0000 +Received: from localhost (localhost [127.0.0.1]) + by mail.ceptacle.com (Postfix) with ESMTP id 40AA0270EBA5 + for <bitcoin-development@lists.sourceforge.net>; + Mon, 3 Dec 2012 14:04:24 +0100 (CET) +X-Virus-Scanned: amavisd-new at ceptacle.com +Received: from mail.ceptacle.com ([127.0.0.1]) + by localhost (server.ceptacle.private [127.0.0.1]) (amavisd-new, + port 10024) with ESMTP id BmCYSICu36ke + for <bitcoin-development@lists.sourceforge.net>; + Mon, 3 Dec 2012 14:04:24 +0100 (CET) +Received: from [109.105.106.201] (unknown [109.105.106.201]) + by mail.ceptacle.com (Postfix) with ESMTPSA id 0ED14270EB98 + for <bitcoin-development@lists.sourceforge.net>; + Mon, 3 Dec 2012 14:04:23 +0100 (CET) +Content-Type: text/plain; charset=us-ascii +Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) +From: Michael Gronager <gronager@ceptacle.com> +In-Reply-To: <CA+s+GJAxGxrtqHSx4ssowg=C=Q+ajELHsEfAgjNh9W2+ExpgVQ@mail.gmail.com> +Date: Mon, 3 Dec 2012 14:04:22 +0100 +Content-Transfer-Encoding: quoted-printable +Message-Id: <9B78C2C9-2B06-47F1-A99D-D36668D97B2D@ceptacle.com> +References: <80648682-E34A-455E-B34A-6BC24652C3EA@ceptacle.com> + <CA+s+GJAxGxrtqHSx4ssowg=C=Q+ajELHsEfAgjNh9W2+ExpgVQ@mail.gmail.com> +To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +X-Mailer: Apple Mail (2.1499) +X-Spam-Score: 0.0 (/) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. +X-Headers-End: 1TfVhF-0003Gp-Tq +Subject: Re: [Bitcoin-development] Chain dust mitigation: Demurrage based + Chain Vacuuming +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Mon, 03 Dec 2012 13:04:35 -0000 + +> 1) Wouldn't the need to re-transact your coins to keep them safe from = +"vultures", result in people frantically sending coins to themselves, = +and thus expand the block chain, instead of reduce growth? + +Not at the rate suggested + +> 2) putting those hard limits in passes a value judgement that IMO = +should not be present in the protocol. <1BTC may be worth a lot some = +day, or it could go the other way around, with dust spam of 10+ BTC. = +Either way the limits will have to be changed again, with yet another = +fork. + +Well, retransmitting 1BTC ones every 4 years isn't that bad. So I don't = +see a need for another fork for this reason. + +> 3) The (normal) user does not have a view of his balance consisting of = +inputs and outputs of various sizes. He just sees his balance as one = +number. And somehow, inexplicably (except through a very difficult = +explanation), it's going down... what if he has 10000 BTC in 0.9999999 = +BTC units? Annnnnd it's gone after 210000 blocks. + +Agree to this - and also to the fact that it will be hard to introduce - = +it would be changing the protocol quite a lot (perhaps too much). + +A better set of relay fee rules rewarding a decrease in # UTXOs is = +probably the (easiest) way forward. + +/M +>=20 + + + |