From: Thomas Guyot-Sionnest <dermoth@aei.ca>
To: Daniele Pinna <daniele.pinna@gmail.com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] UTXO growth scaling solution proposal
Date: Tue, 22 Aug 2017 19:27:30 -0400 [thread overview]
Message-ID: <afba8b41-4391-fd10-beb5-c236d44c55c9@aei.ca> (raw)
In-Reply-To: <CAEgR2PGiP8yom+q-XDPgeoUsJnVfUgVFPx7nvWcpDFqBkm8MBQ@mail.gmail.com>
On 22/08/17 06:17 PM, Daniele Pinna via bitcoin-dev wrote:
> Also.... how is this not a tax on coin holders? By forcing people to
> move coins around you would be chipping away at their wealth in the
> form of extorted TX fees.
>
As if the fee for one tx per decade (or more if we'd like) matters, plus
it could be very low priority. In fact we could re-allow free
transactions based on old priority rules (oldest outputs gets higher
priority... I would suggest considering reduction in utxo size as well
but that's another topic).
Actually, to ensure miners allow these transaction one rule could be
that the block must contain free transactions on old utxo's ("old" TBD)
to reclaim from the scavenged pool... One side effect is that mining
empty blocks before previous block TX can be validated would reduce the
reward.
I'd love to find clever approach where we could somehow make a
verifiable block check that old tx refresh are included... I haven't put
much thoughts into it yet but if there was a way a two-step transaction
where 1. a fee is paid to register an UTXO refresh (miners would be
encouraged to accept it and increase their immediate revenue), and 2.
the fee must be returned from the pool on a later block. The idea is to
allow free scavenging of own addresses while discouraging miners from
refusing free transactions so they could eventually reclaim the coins. I
can't think of a way that limits the burden on consensus rules...
--
Thomas
next prev parent reply other threads:[~2017-08-22 23:27 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-22 22:17 [bitcoin-dev] UTXO growth scaling solution proposal Daniele Pinna
2017-08-22 23:27 ` Thomas Guyot-Sionnest [this message]
-- strict thread matches above, loose matches on Subject: below --
2017-08-22 22:58 Rodney Morris
2017-08-22 23:29 ` Thomas Guyot-Sionnest
2017-08-23 3:26 ` Mark Friedenbach
2017-08-22 8:19 Matthew Beton
2017-08-22 13:45 ` Chris Riley
2017-08-22 14:04 ` Matthew Beton
2017-08-22 14:29 ` Erik Aronesty
2017-08-22 17:24 ` Thomas Guyot-Sionnest
2017-08-22 17:33 ` Matthew Beton
2017-08-22 18:55 ` Chris Riley
2017-08-22 20:06 ` Erik Aronesty
2017-08-22 20:20 ` Mark Friedenbach
2017-07-21 19:28 Major Kusanagi
2017-07-21 19:52 ` Jeremy
2017-07-21 19:54 ` Jameson Lopp
2017-07-22 6:43 ` Major Kusanagi
2017-07-21 19:59 ` Lucas Clemente Vella
2017-07-21 20:17 ` Moral Agent
2017-07-22 6:45 ` Major Kusanagi
2017-08-21 13:35 ` Thomas Guyot-Sionnest
2017-08-21 14:26 ` Moral Agent
2017-08-21 17:24 ` Erik Aronesty
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=afba8b41-4391-fd10-beb5-c236d44c55c9@aei.ca \
--to=dermoth@aei.ca \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=daniele.pinna@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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