Instead of thinking in terms of blocking uneconomical transactions (how
would a node even determine what's economical?), what about thinking in
terms of paying for a feed of economical (i.e. profitable) transactions?
There is a market for fee bearing, profitable transactions...if there is no
one
Just activate a non-proportional demurrage
demurrage of any kind will never, ever happen, just give up on that idea.
The negative publicity of the bitcoin developers are destroying YOUR
coins! would be devastating.
--
--
Gavin Andresen
Why does demurrage even still come up? The base rules of Bitcoin will
not be changing in such a fundamental way.
With regards to trying to minimize the size of the UTXO set, this
again feels like a solution in search of a problem. Even with SD
abusing micropayments as messages, it's only a few
That solution seems good enough to me.
Smartcoin users would just need to move their assets before 10 years,
totally acceptable.
And regular users don't need to think about it since they're probably
always sending more than they pay in fees.
On 3/11/13, Benjamin Lindner b...@benlabs.net wrote:
On 03/11/2013 08:17 PM, Benjamin Lindner wrote:
The problem of UTXO in principal scales with the block size limit. Thus it
should be fixed BEFORE you consider increasing the block size limit.
Otherwise you just kick the can down the road, making it bigger.
Let's assume bitcoin has scaled up
The point with UTXO is in the long run to be able to switch from a p2p network
where everyone stores, validates and verifies everything to a DHT where the
load of storing, validating and verifying can be shared.
If we succeed with that then I don't see a problem in a growing set of UTXO,
may
On Mon, Mar 11, 2013 at 1:36 PM, Michael Gronager grona...@ceptacle.com wrote:
The point with UTXO is in the long run to be able to switch from a p2p
network where everyone stores, validates and verifies everything to a DHT
where the load of storing, validating and verifying can be shared.
I
This would be bloating UTXO data at a speed of 52 GB/year. That's a very
big memory leak. And this is just the unspendable outputs.
Firstly, the UTXO set is a LevelDB, it's not stored in memory. Outputs
that never get spent are not in the working set by definition, after a
while they just end
On 03/12/2013 12:19 AM, Mike Hearn wrote:
Firstly, the UTXO set is a LevelDB, it's not stored in memory. Outputs
that never get spent are not in the working set by definition, after a
while they just end up in the bottom levels and hardly ever get
accessed. If need be we can always help
On 03/12/2013 12:39 AM, Mike Hearn wrote:
RAM is used as a database cache.
But regardless, what kind of attack are you thinking of? Using up all
available disk seeks by sending a node a lot of fake transactions that
connect to unspent outputs, but have invalid transactions? You'll get
10 matches
Mail list logo
