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
On Monday, March 11, 2013 7:27:51 PM Rune K. Svendsen wrote:
From: Rune K. Svendsen runesv...@gmail.com
On the Main tab in the Options dialog, it previously said a minimum
fee of 0.01 is recommended. This amounts to about $0.50 at today's
price. Change this to 0.001 to be more sensible. We
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
On Mon, Mar 11, 2013 at 9:46 PM, Luke-Jr l...@dashjr.org wrote:
On Monday, March 11, 2013 8:34:52 PM Rune Kjær Svendsen wrote:
Ok. I'll fork on Github. Looking at the source, and some Qt
documentation,
it should be doable to do string substitution for both the value and the
unit.
Side
On Monday, March 11, 2013 9:17:25 PM Rune Kjær Svendsen wrote:
On Mon, Mar 11, 2013 at 9:46 PM, Luke-Jr l...@dashjr.org wrote:
On Monday, March 11, 2013 8:34:52 PM Rune Kjær Svendsen wrote:
Ok. I'll fork on Github. Looking at the source, and some Qt
documentation,
it should be
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
Say Alice signs and broadcasts a tx with input Ai, with SIGHASH_SINGLE
to Ao and SIGHASH_ANYONECANPAY
Bob signs and broadcasts a tx with input Bi, with SIGHASH_SINGLE to Bo
and SIGHASH_ANYONECANPAY
Can Carol complete the tx so that it is valid to be published in the chain?
It only has to make Ai
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
Hello everyone,
Í've just seen many reports of 0.7 nodes getting stuck around block 225430,
due to running out of lock entries in the BDB database. 0.8 nodes do not
seem to have a problem.
In any case, if you do not have this block:
2013-03-12 00:00:10 SetBestChain: new
14 matches
Mail list logo
