Bob McElrath [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-08-10 to 2021-12-15
💬 Posted a total of 28 messages
📚 Participated in the following categories: Bitcoin-development, bitcoin-dev, Bitcoin Advent Calendar
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 23:01:26

- reply

📅 Original date posted:2021-12-14
📝 Original message:This, quite simply, is not a "pool". A pool is by definition a tool to reduce
profit variance by miners by collecting "weak blocks" that do not meet the
difficulty target, so as to get a better statistical measure of each miner's
hashrate, which is used to subdivide profits. These are called "shares" and are
entirely absent here.
The only available information here to decide payouts is the blocks themselves,
I do not have any higher statistics measurement to subdivide payments. If I
expect to earn 3 blocks within the window, sometimes I will earn 2 and sometimes
I will earn 4. Whether I keep the entire coinbase in those 2-4 blocks, or I have
100 other miners paying me 1/100 as much 100 times, my payment is the same and
must be proportional to the number of blocks I mine in the window. My variance
is not reduced.
Further, by making miners pay other miners within the window N, this results in
N^2 payments to miners which otherwise would have had N coinbase payments. So,
this is extremely block-space inefficient for no good reason. P2Pool had the
same problem and generated giant coinbases which competed with fee revenue.
"Congestion control" makes this somewhat worse since is it is an absolute
increase in the block space consumed for these N^2 payments.
The only thing this proposal does do is smooth out fee revenue. While hedging on
fee revenue is valuable, this is an extremely complicated and expensive way to
go about it, that simultaneously *reduces* fee revenue due to all the extra
block space used for miner payouts.
Jeremy via bitcoin-dev [bitcoin-dev at lists.linuxfoundation.org] wrote:
> Howdy, welcome to day 15!
>
> Today's post covers a form of a mining pool that can be operated as sort of a
> map-reduce over blocks without any "infrastructure".
>
> https://rubin.io/bitcoin/2021/12/12/advent-15/
>
> There's still some really open-ended questions (perhaps for y'all to consider)
> around how to select an analyze the choice of window and payout functions, but
> something like this could alleviate a lot of the centralization pressures
> typically faced by pools.
>
> Notably, compared to previous attempts, combining the payment pool payout with
> this concept means that there is practically very little on-chain overhead from
> this approach as the chain-load
> for including payouts in every block is deferred for future cooperation among
> miners. Although that can be considered cooperation itself, if you think of it
> like a pipeline, the cooperation happens out of band from mining and block
> production so it really is coordination free to mine.
>
>
> Cheers,
>
> Jeremy
>
> --
> @JeremyRubin
> !DSPAM:61b626be345321821816715!
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> !DSPAM:61b626be345321821816715!
--
Cheers, Bob McElrath
"For every complex problem, there is a solution that is simple, neat, and wrong."
-- H. L. Mencken

2023-06-07 23:01:21

- reply

📅 Original date posted:2021-12-15
📝 Original message:You basically described Braidpool:
https://github.com/pool2win/braidpool
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-August/019371.html
We're working on this actively and will have some updates soon. Additional
contributors are most welcome.
To your points below:
1. Increased payout regularity does not lower the viable size of mining pools,
because smaller mining pools using this mechanism still have higher variance.
2. The on-chain footprint is *higher* due to the increased payout regularity.
For a talk a while back I computed that if you want to have a 1% annual variance
on your profits, you need a pool that is about 20% of the network. The only way
to get this is with smaller, faster blocks or "shares".
https://www.youtube.com/watch?v=91WKy7RYHD4
There is a discussion forum at:
https://matrix.to/#/#braidpool:matrix.org
and a mailing list:
https://sourceforge.net/p/braidpool/mailman/
All of the existing discussion has been happening privately unfortunately but
I'll try to start using Matrix. ;-)
We've been discussing alternatives for both fee-rate and hashrate derivatives
lately. I'm not opposed to using CTV for some of the things in braidpool, if it
makes sense. Payment pools and unilateral channel openings may be interesting in
this context.
P.S. if anyone wants me to write up a blurb of exactly *why* a construction
without shares cannot be used for hashrate derivatives I can do that, just ask.
It comes down to maximum likelihood estimators for the Poisson distribution...
Billy Tetrud [billy.tetrud at gmail.com] wrote:
> Looks like an interesting proposal, but it doesn't seem to quite match the
> goals you mentioned. As you do mention, this mining pool coordination doesn't
> get rid of the need for mining pools in the first place. So it doesn't satisfy
> item 1 on your goal list afaict.
>
> The primary benefits over what we have today that I can see are:
> 1. increased payout regularity, which lowers the viable size of mining pools,
> and
> 2. Lower on chain footprint through combining pay outs from multiple pools.
>
> Am I missing some?
>
> These are interesting benefits, but it would be nice if your post was clearer
> on that, since the goals list is not the same as the list of potential benefits
> of this kind of design.
>
> As far as enabling solo mining, what if this concept were used off chain? Have
> a public network of solo miners who publish "weak blocks" to that network, and
> the next 100 (or 1000 etc) nice miners pay you out as long as you're also being
> nice by following the protocol? All the nice optimizations you mentioned about
> eg combined taproot payouts would apply i think. The only goals this wouldn't
> satisfy are 3 and 5 since an extra network is needed, but to be fair, your
> proposal requires pools which all need their own extra network anyways.
>
> The missing piece here would be an ordering of weak blocks to make the window
> possible. Or at least a way to determine what blocks should definitely be part
> of a particular block's pay out. I could see this being done by a separate
> ephemeral blockchain (which starts fresh after each Bitcoin block) that keeps
> track of which weak blocks have been submitted, potentially using the pow
> already in each block to secure it. Granted that piece is a bit half baked, but
> it seems quite solvable. Wdyt?
>
> One thing that jumped out at me as not safe is throwing block rewards into a
> channel and being able to spend them immediately. There's a reason block
> rewards aren't spendable for a while, and channels don't solve that problem, do
> they? Why not simply reduce the on chain wait time for spending block rewards
> at that point? Seems like the consequences would be the same.
>
> On Tue, Dec 14, 2021, 16:12 Bob McElrath via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> You are hand waving. Attempting to redefine terms to justify your argument
> is
> intellectually dishonest. Bitcoin pools have *always* been about variance
> reduction. Your window function fundamentally CANNOT be used to hedge
> hashrate.
> Various suggestions below introduce dangerous new games that might be
> played by
> miners.
>
> The fact is that the half-baked design you posted is less than useless, and
> doesn't do anything that anyone wants.
>
> You are trying to justify CTV by making it be all things to all people.
> "When
> all you have is a hammer, every problem looks like a nail". Instead I
> humbly
> suggest that you pick ONE problem for which CTV is demonstrably the right
> and
> best solution, instead of snowing us with a ton of half-baked things that
> *could* be done, and often don't even require CTV, and some (like this one)
> fundamentally don't work. I do like some of your ideas, but if you had to
> pick
> just one "use case", which would it be?
>
> Jeremy [jlrubin at mit.edu] wrote:
> > Bitcoin didn't invent the concept of pooling: https://en.wikipedia.org/
> wiki/
> > Pooling_(resource_management). This is a Bitcoin Mining Pool, although it
> may
> > not be your favorite kind, which is fixated on specific properties of
> computing
> > contributions before finding a block. Pooling is just a general technique
> for
> > aggregating resources to accomplish something. If you have another name
> like
> > pooling that is in common use for this type of activity I would be more
> than
> > happy to adopt it.
> >
> > This sort of pool can hedge not only against fee rates but also against
> > increases in hashrate since your historical rate 'carries' into the
> future as a
> > function of the window. Further, windows and reward functions can be
> defined in
> > a myriad of ways that could, e.g., pay less to blocks found in more rapid
> > succession, contributing to the smoothing functionality.
> >
> > With respect to sub-block pooling, as described in the article, this sort
> of
> > design also helps with micro-pools being able to split resources
> > non-custodially in every block as a part of the higher order DCFMP. The
> point
> > is not, as noted, to enable solo mining an S9, but to decrease the size
> of the
> > minimum viable pool. It's also possible to add, without much validation
> or
> > data, some 'uncle block' type mechanism in an incentive compatible way
> (e.g.,
> > add 10 pow-heavy headers on the last block for cost 48 bytes header + 32
> bytes
> > payout key) such that there's an incentive to include the heaviest ones
> you've
> > seen, not just your own, that are worth further study and consideration
> > (particularly because it's non-consensus, only for opt-in participation
> in the
> > pool).
> >
> > With respect to space usage, it seems you wholly reject the viability of
> a
> > payment pool mechanism to cut-through chain space. Is this a critique
> that
> > holds for all Payment Pools, or just in the context of mining? Is there a
> > particular reason why you think it infeasible that "strongly online"
> > counterparties would be able to coordinate more efficiently? Is it
> preferable
> > for miners, the nexus of decentralization for Bitcoin, to prefer to use
> > custodial services for pooling (which may require KYC/AM) over bearing a
> cost
> > of some extra potential chainload?
> >
> > Lastly, with respect to complexity, the proposal is actually incredibly
> simple
> > when you take it in a broader context. Non Interactive Channels and
> Payment
> > Pools are useful by themselves, so are the operations to merge them and
> swap
> > balance across them. Therefore most of the complexity in this proposal is
> > relying on tools we'll likely see in everyday use in any case, DCFMP or
> no.
> >
> > Jeremy
> >
> --
> Cheers, Bob McElrath
>
> "For every complex problem, there is a solution that is simple, neat, and
> wrong."
> -- H. L. Mencken
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> !DSPAM:61ba2512470948607217095!
--
Cheers, Bob McElrath
"For every complex problem, there is a solution that is simple, neat, and wrong."
-- H. L. Mencken

2023-06-07 23:01:19

- reply

📅 Original date posted:2021-12-14
📝 Original message:You are hand waving. Attempting to redefine terms to justify your argument is
intellectually dishonest. Bitcoin pools have *always* been about variance
reduction. Your window function fundamentally CANNOT be used to hedge hashrate.
Various suggestions below introduce dangerous new games that might be played by
miners.
The fact is that the half-baked design you posted is less than useless, and
doesn't do anything that anyone wants.
You are trying to justify CTV by making it be all things to all people. "When
all you have is a hammer, every problem looks like a nail". Instead I humbly
suggest that you pick ONE problem for which CTV is demonstrably the right and
best solution, instead of snowing us with a ton of half-baked things that
*could* be done, and often don't even require CTV, and some (like this one)
fundamentally don't work. I do like some of your ideas, but if you had to pick
just one "use case", which would it be?
Jeremy [jlrubin at mit.edu] wrote:
> Bitcoin didn't invent the concept of pooling: https://en.wikipedia.org/wiki/
> Pooling_(resource_management). This is a Bitcoin Mining Pool, although it may
> not be your favorite kind, which is fixated on specific properties of computing
> contributions before finding a block. Pooling is just a general technique for
> aggregating resources to accomplish something. If you have another name like
> pooling that is in common use for this type of activity I would be more than
> happy to adopt it.
>
> This sort of pool can hedge not only against fee rates but also against
> increases in hashrate since your historical rate 'carries' into the future as a
> function of the window. Further, windows and reward functions can be defined in
> a myriad of ways that could, e.g., pay less to blocks found in more rapid
> succession, contributing to the smoothing functionality.
>
> With respect to sub-block pooling, as described in the article, this sort of
> design also helps with micro-pools being able to split resources
> non-custodially in every block as a part of the higher order DCFMP. The point
> is not, as noted, to enable solo mining an S9, but to decrease the size of the
> minimum viable pool. It's also possible to add, without much validation or
> data, some 'uncle block' type mechanism in an incentive compatible way (e.g.,
> add 10 pow-heavy headers on the last block for cost 48 bytes header + 32 bytes
> payout key) such that there's an incentive to include the heaviest ones you've
> seen, not just your own, that are worth further study and consideration
> (particularly because it's non-consensus, only for opt-in participation in the
> pool).
>
> With respect to space usage, it seems you wholly reject the viability of a
> payment pool mechanism to cut-through chain space. Is this a critique that
> holds for all Payment Pools, or just in the context of mining? Is there a
> particular reason why you think it infeasible that "strongly online"
> counterparties would be able to coordinate more efficiently? Is it preferable
> for miners, the nexus of decentralization for Bitcoin, to prefer to use
> custodial services for pooling (which may require KYC/AM) over bearing a cost
> of some extra potential chainload?
>
> Lastly, with respect to complexity, the proposal is actually incredibly simple
> when you take it in a broader context. Non Interactive Channels and Payment
> Pools are useful by themselves, so are the operations to merge them and swap
> balance across them. Therefore most of the complexity in this proposal is
> relying on tools we'll likely see in everyday use in any case, DCFMP or no.
>
> Jeremy
> !DSPAM:61b8f2f5321461582627336!
--
Cheers, Bob McElrath
"For every complex problem, there is a solution that is simple, neat, and wrong."
-- H. L. Mencken

2023-06-07 18:27:12

- reply

📅 Original date posted:2020-10-08
📝 Original message:A diversion on statistics:
There are two quantities available for consensus:
t target difficulty
h block hash where h < t
>From these we can form two quantities that might be used in consensus:
w work = log(sum(1/t_i))
f fitness = log(sum(1/h_i)) (term used by authors)
(The original authors do not specify mathematically how they obtain their
numbers -- but it doesn't really matter, fundamentally, they want to use the
block hash h instead of t) Bitcoin introduces some constants in the above sums
which I omit for clarity.
The main point here is that the work w is an unbiased statistical estimator for
the number of sha256d computations performed by the network. It is truly a
measurement of "work". The fitness f is a *biased* estimator for exactly the
same thing, and other than introducing statistical bias, provides no additional
information of any value.
The fundamental question of FPNC as I understand it is: should we introduce the
historic block hash h as a consensus-critical parameter?
The answer is a strict no: This quantity f (fitness) is purely random, and does
not in any way favor the "honest" chain, nor can it identify it. Between two
competing chains, the amount of bias on one chain vs. the other is purely random
and does *not* reflect more work done by one side or the other. Nor can it have
any knowledge of things like network splits.
At constant difficulty assuming two competing chains with exactly the same
number of blocks and amount of hashpower, this bias will oscillate, sometimes
favoring one side, sometimes favoring the other. Unlike work, this bias is not
cumulative. Each side will over time converge to having the same amount of bias
from any biased estimator such as f constructed from the hashes h. Just because
one side had an abnormally small hash doesn't mean the other side won't have a
similar abnormally low hash. The expectation value for the amount of bias is
equal on both sides.
Therefore, hard NACK on using h in this way and FPNP. At best it introduces
unecessary randomness into the chain selection process, at worst it proves a new
game to be played by miners. As a consensus critical change, it's also
incredibly risky to push through without some very serious advantage, which this
does not have.
--
Cheers, Bob McElrath
"For every complex problem, there is a solution that is simple, neat, and wrong."
-- H. L. Mencken

2023-06-07 17:49:33

- reply

📅 Original date posted:2016-03-09
📝 Original message:Dave Hudson [dave at hashingit.com] wrote:
> A damping-based design would seem like the obvious choice (I can think of a
> few variations on a theme here, but most are found in the realms of control
> theory somewhere). The problem, though, is working working out a timeframe
> over which to run the derivative calculations.
>From a measurement theory perspective this is straightforward. Each block is a
measurement, and error propagation can be performed to derive an error on the
derivatives.
The statistical theory of Bitcoin's block timing is known as a Poisson Point
Process: https://en.wikipedia.org/wiki/Poisson_point_process or temporal point
process. If you google those plus "estimation" you'll find a metric shit-ton of
literature on how to handle this.
> The problem is the measurement of the hashrate, which is pretty inaccurate at
> best because even 2016 events isn't really enough (with a completely constant
> hash rate running indefinitely we'd see difficulty swings of up to +/- 5% even
> with the current algorithm). In order to meaningfully react to a major loss
> of hashing we'd still need to be considering a window of probably 2 weeks.
You don't want to assume it's constant in order to get a better measurement.
The assumption is clearly false. But, errors can be calculated, and retargeting
can take errors into account, because no matter what we'll always be dealing
with a finite sample.
Personally I don't think difficulty target variations are such a big deal, if
the algorithm targets that over any long time interval, the average block time
is 10 min. Bitcoin's current algorithm fails here, with increasing hashrate (as
we have), it issues coins faster than its assumed schedule.
--
Cheers, Bob McElrath
"For every complex problem, there is a solution that is simple, neat, and wrong."
-- H. L. Mencken

2023-06-07 17:49:32

- reply

📅 Original date posted:2016-03-08
📝 Original message:Dave Hudson via bitcoin-dev [bitcoin-dev at lists.linuxfoundation.org] wrote:
> I think the biggest question here would be how would the difficulty
> retargeting be changed? Without seeing the algorithm proposal it's difficult
> to assess the impact that it would have, but my intuition is that this is
> likely to be problematic.
I have no comment on whether this will be *needed* but there's a simple
algorithm that I haven't seen any coin adopt, that I think needs to be: the
critically damped harmonic oscillator:
http://mathworld.wolfram.com/CriticallyDampedSimpleHarmonicMotion.html
In dynamical systems one does a derivative expansion. Here we want to find the
first and second derivatives (in time) of the hashrate. These can be determined
by a method of finite differences, or fancier algorithms which use a quadratic
or quartic polynomial approximation. Two derivatives are generally all that is
needed, and the resulting dynamical system is a damped harmonic oscillator.
A damped harmonic oscillator is basically how your car's shock absorbers work.
The relevant differential equation has two parameters: the oscillation frequency
and damping factor. The maximum oscillation frequency is the block rate. Any
oscillation faster than the block rate cannot be measured by block times. The
damping rate is an exponential decay and for critical damping is twice the
oscillation frequency.
So, this is a zero parameter, optimal damping solution for a varying hashrate.
This is inherently a numeric approximation solution to a differential equation,
so questions of approximations for the hashrate enter, but that's all. Weak
block proposals will be able to get better approximations to the hashrate.
If solving this problem is deemed desirable, I can put some time into this, or
direct others as to how to go about it.
--
Cheers, Bob McElrath
"For every complex problem, there is a solution that is simple, neat, and wrong."
-- H. L. Mencken

2023-06-07 17:43:29

- reply

📅 Original date posted:2015-10-14
📝 Original message:So it seems to me that all I need to do is figure out who the current leader is,
and DDoS him off the network to shut Bitcoin-NG down.
This is a significant advantage to bitcoin's ex-post-facto blocks: no one knows
where the next one will come from. The only way to shut the network down is to
shut all nodes down.
Emin Gün Sirer via bitcoin-dev [bitcoin-dev at lists.linuxfoundation.org] wrote:
> Hi everyone,
>
> We just released the whitepaper describing Bitcoin-NG, a new technique for
> addressing some of the scalability challenges faced by Bitcoin. Surprisingly,
> Bitcoin-NG can simultaneously increase throughput while reducing latency, and
> do so without impacting Bitcoin's open architecture or changing its trust
> model. This post illustrates the core technique:
> http://hackingdistributed.com/2015/10/14/bitcoin-ng/
> while the whitepaper has all the nitty gritty details:
> http://arxiv.org/abs/1510.02037
>
> Fitting NG on top of the current Bitcoin blockchain is future work that we
> think is quite possible. NG is compatible with both Bitcoin as is, as well as
> Blockstream-like sidechains, and we currently are not planning to compete
> commercially with either technology -- we see NG as being complementary to both
> efforts. This is pure science, published and shared with the community to
> advance the state of blockchains and to help them reach throughputs and
> latencies required of cutting edge fintech applications. Perhaps it can be
> adopted, or perhaps it can provide the spark of inspiration for someone else to
> come up with even better solutions.
>
> We would be delighted to hear your feedback.
> - Ittay Eyal and E. Gün Sirer.
>
> !DSPAM:561e98cd301391127216946!
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> !DSPAM:561e98cd301391127216946!
--
Cheers, Bob McElrath
"For every complex problem, there is a solution that is simple, neat, and wrong."
-- H. L. Mencken

2023-06-07 15:34:27

- reply

📅 Original date posted:2015-05-10
📝 Original message:That's a lot of work, a lot of extra utxo's, and a lot of blockchain spam, just
so I can do a convoluted form of arithmetic on my balance.
If a tx contained an explicit miner fee and a change address, but did not
compute the change, letting the network compute it (and therefore merge
transactions spending the same utxo), could one add some form of ring signature
a la Dash to alleviate the worsened privacy implications?
Jeff Garzik [jgarzik at bitpay.com] wrote:
> This has been frequently explored on IRC.
>
> My general conclusion is "dollar bills" - pick highly common denominations of
> bitcoins. Aggregate to obtain these denominations, but do not aggregate
> further.
>
> This permits merge avoidance (privacy++), easy coinjoin where many hide in the
> noise (privacy++), wallet dust de-fragmentation, while avoiding the
> over-aggregation problem where you have consolidated down to one output.
>
> Thus a wallet would have several consolidation targets.
>
> Another strategy is simply doubling outputs. Say you pay 0.1 BTC to
> Starbucks. Add another 0.1 BTC output to yourself, and a final change output.
> Who can say which output goes to Starbucks?
>
> There are many iterations and trade-offs between fragmentation and privacy.
--
Cheers, Bob McElrath
"The individual has always had to struggle to keep from being overwhelmed by
the tribe. If you try it, you will be lonely often, and sometimes frightened.
But no price is too high to pay for the privilege of owning yourself."
-- Friedrich Nietzsche

2023-06-07 15:34:25

- reply

📅 Original date posted:2015-05-10
📝 Original message:This is my biggest headache with practical bitcoin usage. I'd love to hear it if
anyone has any clever solutions to the wallet/utxo locked problem. Spending
unconfirmed outputs really requires a different security model on the part of
the receiver than #confirmations, but isn't inherently bad if the receiver has a
better security model and knows how to compute the probability that an
unconfirmed-spend will get confirmed. Of course the bigger problem is wallet
software that refuses to spend unconfirmed outputs.
I've thought a bit about a fork/merge design: if the change were computed by the
network instead of the submitter, two transactions having the same change
address and a common input could be straightforwardly merged or split (in a
reorg), where with bitcoin currently it would be considered a double-spend. Of
course that has big privacy implications since it directly exposes the change
address, and is a hard fork, but is much closer to what people expect of a
debit-based "account" in traditional banking.
The fact of the matter is that having numerous sequential debits on an account
is an extremely common use case, and bitcoin is obtuse in this respect.
On May 9, 2015 1:09:32 PM EDT, Jim Phillips <jim at ergophobia.org> wrote:
>Forgive me if this idea has been suggested before, but I made this
>suggestion on reddit and I got some feedback recommending I also bring
>it
>to this list -- so here goes.
>
>I wonder if there isn't perhaps a simpler way of dealing with UTXO
>growth.
>What if, rather than deal with the issue at the protocol level, we deal
>with it at the source of the problem -- the wallets. Right now, the
>typical
>wallet selects only the minimum number of unspent outputs when building
>a
>transaction. The goal is to keep the transaction size to a minimum so
>that
>the fee stays low. Consequently, lots of unspent outputs just don't get
>used, and are left lying around until some point in the future.
>
>What if we started designing wallets to consolidate unspent outputs?
>When
>selecting unspent outputs for a transaction, rather than choosing just
>the
>minimum number from a particular address, why not select them ALL? Take
>all
>of the UTXOs from a particular address or wallet, send however much
>needs
>to be spent to the payee, and send the rest back to the same address or
>a
>change address as a single output? Through this method, we should wind
>up
>shrinking the UTXO database over time rather than growing it with each
>transaction. Obviously, as Bitcoin gains wider adoption, the UTXO
>database
>will grow, simply because there are 7 billion people in the world, and
>eventually a good percentage of them will have one or more wallets with
>spendable bitcoin. But this idea could limit the growth at least.
>
>The vast majority of users are running one of a handful of different
>wallet
>apps: Core, Electrum; Armory; Mycelium; Breadwallet; Coinbase; Circle;
>Blockchain.info; and maybe a few others. The developers of all these
>wallets have a vested interest in the continued usefulness of Bitcoin,
>and
>so should not be opposed to changing their UTXO selection algorithms to
>one
>that reduces the UTXO database instead of growing it.
>
>>From the miners perspective, even though these types of transactions
>would
>be larger, the fee could stay low. Miners actually benefit from them in
>that it reduces the amount of storage they need to dedicate to holding
>the
>UTXO. So miners are incentivized to mine these types of transactions
>with a
>higher priority despite a low fee.
>
>Relays could also get in on the action and enforce this type of
>behavior by
>refusing to relay or deprioritizing the relay of transactions that
>don't
>use all of the available UTXOs from the addresses used as inputs.
>Relays
>are not only the ones who benefit the most from a reduction of the UTXO
>database, they're also in the best position to promote good behavior.
>
>--
>*James G. Phillips IV*
><https://plus.google.com/u/0/113107039501292625391/posts>
>
>*"Don't bunt. Aim out of the ball park. Aim for the company of
>immortals."
>-- David Ogilvy*
>
>*This message was created with 100% recycled electrons. Please think
>twice
>before printing.*
>
>
>!DSPAM:554e4e5450787476022393!
>
>
>------------------------------------------------------------------------
>
>------------------------------------------------------------------------------
>One dashboard for servers and applications across
>Physical-Virtual-Cloud
>Widest out-of-the-box monitoring support with 50+ applications
>Performance metrics, stats and reports that give you Actionable
>Insights
>Deep dive visibility with transaction tracing using APM Insight.
>http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>
>!DSPAM:554e4e5450787476022393!
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development at lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>!DSPAM:554e4e5450787476022393!
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150510/3d3c3382/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150510/3d3c3382/attachment.sig>