I'm not sure I understand your proposal, but its sounds good.
Can you elaborate with an example?
Are you considering colored coins/smart property?
On 3/13/13, Stephen Pair wrote:
> Instead of thinking in terms of blocking uneconomical transactions (how
> would a node even determine what's econom
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 wi
On Sat, Mar 09, 2013 at 11:31:55PM -0500, Peter Todd wrote:
> As discussed endlessly data in the UTXO set is more costly, especially
> in the long run, than transaction data itself. The fee system is per KB
> in a block, and thus doesn't properly capture the long-term costs of
> UTXO creation.
The
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
> y
> Isn't there danger of an attack if UTXO is not stored in fast storage?
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 trans
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 Lev
> 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
>> 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 believe you are confusing disjoint things.
Nope, ahh well, I agree t
On Mon, Mar 11, 2013 at 1:36 PM, Michael Gronager 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 believe you are co
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 t
On Mon, Mar 11, 2013 at 12:01 PM, Jorge Timón wrote:
> On 3/10/13, Peter Todd wrote:
> > It's also been suggested multiple times to make transaction outputs with
> > a value less than the transaction fee non-standard, either with a fixed
> > constant or by some sort of measurement.
>
> As said o
On Mon, Mar 11, 2013 at 11:17 AM, Benjamin Lindner wrote:
> > Just activate a non-proportional
> > demurrage (well, I won't complain if you just turn bitcoin into
> > freicoin, just think that non-proportional would be more acceptable by
> > most bitcoiners) that incentives old transactions to be
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 u
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 wrote:
>
> On Mar 11, 201
On Mar 11, 2013, at 12:54 PM, Mike Hearn wrote:
> 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 hundred megabytes
> today. That fits in RAM, let alone disk.
On Mon, Mar 11, 2013 at 11:36 AM, Gavin Andresen
wrote:
>> 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.
While 100%
Well, my initial idea was that nothing was really needed too.
But if something must be done, I dislike very much the "ban
micropayments" approach. I was just offering other solutions that I
consider much better, but if nothing is done I won't be pushing for
those alternative solutions (to a problem
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 hun
Unless of course everlasting physical "bitcoins" are much more
important than smart property and colored coins...
On 3/11/13, Jorge Timón wrote:
> "The Bitcoin network will destroy your coins IF you don't move your coins"
> Is pretty different. By the way, doesn't have to destroy them, can
> jus
"The Bitcoin network will destroy your coins IF you don't move your coins"
Is pretty different. By the way, doesn't have to destroy them, can
just give them to miners.
In any case, what's wrong with my reasoning?
Smart property/colored coins are not spam transactions because they pay fees.
The pr
> 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
--
On 3/10/13, Peter Todd wrote:
> It's also been suggested multiple times to make transaction outputs with
> a value less than the transaction fee non-standard, either with a fixed
> constant or by some sort of measurement.
As said on the bitcointalk thread, I think this is the wrong approach.
This
As discussed endlessly data in the UTXO set is more costly, especially
in the long run, than transaction data itself. The fee system is per KB
in a block, and thus doesn't properly capture the long-term costs of
UTXO creation.
It's also been suggested multiple times to make transaction outputs wit
23 matches
Mail list logo
