Hello again,
block 015c50b165fcdd33556f8b44800c5298943ac70b112df480c023
(height=225430) seems indeed to have cause pre-0.8 and 0.8 nodes to fork
(at least mostly). Both chains are being mined on - the 0.8 one growing
faster.
After some emergency discussion on #bitcoin-dev, it seems be
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
best=015aab
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
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 +
> 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
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 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 doab
On Mon, Mar 11, 2013 at 9:46 PM, Luke-Jr 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 note: I
>> 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 1:34 PM, Rune Kjær Svendsen wrote:
> The question is if we should define a new value, that we use solely to
> display in this text, or if we should use MIN_TX_FEE or MIN_RELAY_TX_FEE in
> some way. What are the dev's thoughts?
It should be a new value.
---
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.
The question is if we should define a new value, that we use solely to
display in this text, or if we should use MIN_TX_FEE or MIN_RELAY_TX_FEE
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 Monday, March 11, 2013 7:27:51 PM Rune K. Svendsen wrote:
> From: "Rune K. Svendsen"
>
> 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 could even go
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
From: "Rune K. Svendsen"
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 could even go
lower, perhaps.
---
src/qt/forms/optionsdialog.ui |2 +-
src/qt/l
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
28 matches
Mail list logo
