From: Alan Reiner <etotheipi@gmail•com>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
Date: Mon, 03 Dec 2012 10:17:30 -0500 [thread overview]
Message-ID: <50BCC28A.4060503@gmail.com> (raw)
In-Reply-To: <CAAS2fgTL=s-vvGsubUu9ZBMidd0wzZdVPb6rEUg+eTMaiipRbA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1756 bytes --]
On 12/03/2012 10:02 AM, Gregory Maxwell wrote:
> (1) Make client software aggressive about sweeping up dust inputs:
> "Any time a transaction is created that has change keep adding in
> extra inputs— smallest to largest— until an additional one would
> increase the cost of the transaction by 0.0001 BTC or more" — the only
> major complication is doing this without concurrently harming privacy
> which is why it's not done yet in the reference client.
FYI, Armory uses exactly this logic to try to clean up dust outputs in
the user's transactions. However, there's enough conditions on it, that
I don't know how often it triggers. Recommendations are welcome for how
to improve it.
Right now, if the transaction has less than 5 inputs, there exists dust
UTXOs from addresses already included in the transaction, and those
UTXOs are sufficiently small in priority, then the Armory will add them
to the input side and increase the change accordingly. Looking it just
made me realize I lost the last condition of making sure the tx already
has a change output -- don't want to turn a free tx into a fee-needed tx
just to do this. (reorganized the code
<https://github.com/etotheipi/BitcoinArmory/blob/master/armoryengine.py#L5279>
recently, and must have fell through the cracks).
Perhaps it could be improved by cleaning up dust from *any* address by
default (not just ones already included in the tx), with the option for
the user to disable that behavior. After all, anonymity was never a
core feature of the network -- I think it makes sense that the logic
would reduce anonymity by default in exchange for a cleaner network,
with a clear option to "opt-out" of that logic if user cares. I think
most users don't actually care...
-Alan
[-- Attachment #2: Type: text/html, Size: 2294 bytes --]
next prev parent reply other threads:[~2012-12-03 15:18 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
2012-12-03 15:02 ` Gregory Maxwell
2012-12-03 15:17 ` Alan Reiner [this message]
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=50BCC28A.4060503@gmail.com \
--to=etotheipi@gmail$(echo .)com \
--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