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
Thanks Chris.
Yep, looks like an honest-ish user managed to accidentally get one tx into
one chain and another into the other.
I think I'd cautiously say that if OKPay gets their cash back, or freezes
his balance nobody is out BTC for last night, (instead just time and
effort).
I'm doing a littl
Just a quick and dirty check if something bad actually happened. 430
transactions that were confirmed in the alt-chain, are not confirmed
in the true blockchain. The good news is that as far as I can tell
most of them are low volume transactions destined for SD.
7 transactions were true double spe
On Tue, Mar 12, 2013 at 11:09 AM, Gregory Maxwell wrote:
> On Tue, Mar 12, 2013 at 10:35 AM, Peter Vessenes wrote:
>> Can some enterprising soul determine if there were any double-spend attempts?
>> I'm assuming no, and if that's the case, we should talk about that publicly.
[snip]
> I agree it w
On Tue, Mar 12, 2013 at 9:55 AM, Alan Reiner wrote:
> I don't want to misrepresent what happened, but how much of that was really
> a risk? The block was rejected, but the transactions were not.
Some but not much. If someone flooded a bunch of duplicate
concurrently announcing both spends to as
Can some enterprising soul determine if there were any double-spend
attempts?
I'm assuming no, and if that's the case, we should talk about that publicly.
Either way, I think it's generally another test well done by everyone;
people pitched in on PR, tech, communication, yay Bitcoin!
On Tue, M
On Tue, Mar 12, 2013 at 8:10 AM, Luke-Jr wrote:
>
>
> I think we should be careful not to downplay the reality either.
> For a number of hours, transactions could have received up to N
> confirmations
> and then still been reversed. While we could contact the bigger payment
> processors, I saw pe
On Tuesday, March 12, 2013 9:47:00 AM Peter Todd wrote:
> We can allow for transaction replacement for the purpose of adding fees
> to existing transactions safely, and while not increasing the risk of
> double-spends by taking advantage of the stubbed out replacement code.
Side note: Adding fees
On Tue, Mar 12, 2013 at 2:47 AM, Peter Todd wrote:
> Followed by the actual replacement logic. We could change this logic to
> instead evaluate if the candidate replacement does not remove or
> decrease the value of any existing outputs. Adding outputs is ok.
> Changing the set of inputs is also o
>> Forks are caused by rejection criteria, hence:
>> 1. If you introduce new rejection criteria in an upgrade miners should
>> upgrade _first_.
>> 2. If you loosen some rejection criteria miners should upgrade _last_.
>> 3. If you keep the same criteria assume 2.
>
> And ... if you aren't aware t
On 3/12/2013 5:18 AM, Jorge Timón wrote:
> A related question...some people mentioned yesterday on #bitcoin-dev
> that 0.5 appeared to be compatible with 0.8.
> Was that only for the "fatal block" and would have forked 0.8 later
> too or is it something else?
> I'm having a hard time understanding
On Tue, Mar 12, 2013 at 2:10 AM, Mike Hearn wrote:
> BDB ran out of locks.
> However, only on some 0.7 nodes. Others, perhaps nodes using different
> flags, managed it.
> We have processed 1mb sized blocks on the testnet.
> Therefore it isn't presently clear why that particular block caused
> lock
Well a reversed upgrade is an upgrade that went wrong ;)
Anyway, the incident makes it even more important for people to upgrade, well
except, perhaps, for miners...
Forks are caused by rejection criteria, hence:
1. If you introduce new rejection criteria in an upgrade miners should upgrade
_f
A related question...some people mentioned yesterday on #bitcoin-dev
that 0.5 appeared to be compatible with 0.8.
Was that only for the "fatal block" and would have forked 0.8 later
too or is it something else?
I'm having a hard time understanding this 0.5 thing, if someone can
bring some light to
I'm not even sure I'd say the upgrade "went wrong". The problem if
anything is the upgrade didn't happen fast enough. If we had run out
of block space a few months from now, or if miners/merchants/exchanges
had upgraded faster, it'd have made more sense to just roll forward
and tolerate the loss of
On Tuesday, March 12, 2013 7:03:54 AM Alan Reiner wrote:
> I'm sure it won't be long before Slashdot and a variety of sources start
> reporting on this event. Bitcoin has been in the media a lot lately, so
> this story is likely to get some attention. The blowback of this event
> is mostly psycho
On Tue, Mar 12, 2013 at 11:13:09AM +0100, Michael Gronager wrote:
> Yes, 0.7 (yes 0.7!) was not sufficiently tested it had an undocumented and
> unknown criteria for block rejection, hence the upgrade went wrong.
We're using "0.7" as a short moniker for all clients, but this was a limitation
tha
> We just saw a hard-fork happen because we ran into previously unknown
> scaling issues with the current codebase.
Technically, it with the previous codebase ;)
--
Symantec Endpoint Protection 12 positioned as A LEADER i
> clients are anyway keeping, and re-relaying, their own transactions
> and hence it would mean only little, and only little for clients.
Not all end-user clients are always-on though
--
Symantec Endpoint Protection 12 po
On Tue, Mar 12, 2013 at 11:13:09AM +0100, Michael Gronager wrote:
> Following that, increase the soft and hard limit to 1 and eg 10MB, but miners
> should be the last to upgrade.
We just saw a hard-fork happen because we ran into previously unknown
scaling issues with the current codebase. Why fo
On Tue, Mar 12, 2013 at 11:10:47AM +0100, Mike Hearn wrote:
> However, most nodes are not running in such a loop today. Probably
> almost no nodes are.
>
> I suppose you could consider mass node death to be more benign than a
> hard fork, but both are pretty damn serious and warrant immediate
> ac
Yes, 0.7 (yes 0.7!) was not sufficiently tested it had an undocumented and
unknown criteria for block rejection, hence the upgrade went wrong.
More space in the block is needed indeed, but the real problem you are
describing is actually not missing space in the block, but proper handling of
mem
However, most nodes are not running in such a loop today. Probably
almost no nodes are.
I suppose you could consider mass node death to be more benign than a
hard fork, but both are pretty damn serious and warrant immediate
action. Otherwise we're going to see the number of nodes drop sharply
over
On Tue, Mar 12, 2013 at 10:10:15AM +0100, Mike Hearn wrote:
> There are no bounds on the memory pool size. If too many transactions
> enter the pool then nodes will start to die with OOM failures.
> Therefore it is possible that we have a very limited amount of time
> until nodes start dying en-mas
On 3/12/13, Mike Hearn wrote:
> 1) Start aggressively trying to block or down-prioritize SatoshiDice
> transactions at the network level, to buy time and try to avoid
> mempool exhaustion. I don't know a good way to do this, although it
> appears that virtually all their traffic is actually coming
We can allow for transaction replacement for the purpose of adding fees
to existing transactions safely, and while not increasing the risk of
double-spends by taking advantage of the stubbed out replacement code.
Specifically the replacement code allows for the replacement of a
transaction if a tr
Just so we're all on the same page, can someone confirm my
understanding - are any of the following statements untrue?
BDB ran out of locks.
However, only on some 0.7 nodes. Others, perhaps nodes using different
flags, managed it.
We have processed 1mb sized blocks on the testnet.
Therefore it is
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
I'm sure it won't be long before Slashdot and a variety of sources start
reporting on this event. Bitcoin has been in the media a lot lately, so
this story is likely to get some attention. The blowback of this event
is mostly psychological, so I think it would be exceptionally wise to
start prepa
29 matches
Mail list logo
