I waver a bit, but there’s something phony about him that rubs me wrong
I’d always assumed there was some sort of standard based on accounts I see who do that. Maybe not…
One additional thing that might be worth modeling a bit more is the actual impact of such an attack across a long sequence of blocks. Seems like some sort of Markov process with two states (Attacker mined previous block, and there is thus a delayed competition for the next block, or the next block is "fairly" mined).
I'm not immediately seeing closed form solution, so ran a quick simulation and found the following:
1% Attacker and X=10 minutes:
effective hash on delayed block = 2%, and over long chain unchanged at 1%
5% Attacker and X=11 minutes:
effective hash on delayed block = 10.6%, and over long chain 5.6%
10% Attacker and X=12 minutes:
effective hash on delayed block = 20.4%, and over long chain 11.3%
20% Attacker and X=14 minutes:
effective hash on delayed block = 39.3%, and over long chain 25%
Might also be interesting to see impact across difficulty adjustments (all other things being held constant), but haven't looked into that.
Appreciate it. Already got some recs from you a couple weeks ago (included your 02bp writing, moonmath manual, and a couple others I haven't gotten to yet.
Luckily I have enough background on the non-crypto math to get up to speed at a reasonable rate, but still a long way to go.
Will undoubtably have some questions down the line, but just taking in what I can for now
Now applied this to aut-ct in a branch:
https://github.com/AdamISZ/aut-ct/tree/delta
Proving is now down to 1-2 seconds even for large trees like 500K, but this is more from me fixing inefficiencies in my code; the real advantage of their new technique for me is just that they made the algorithms much simpler, *and* we have an easy way to batch proofs now (though I haven't done it).
So currently it's:
1-3 minutes to start up a server (which can be left running as long as you use the same curve tree)
1-2 seconds to do a single curve tree inclusion proof
50ms to verify a proof.
This already usable for the kind of 'satoshi millionaire' proofs like the one in my blog post, with sets of 500K or so and even larger, but for some long running system which wants to update the curve tree with new utxos all the time, like lightning it should be possible to get rid of most of that startup cost by using an 'accumulator update' method as discussed in the paper(s).
Still a long way from being able to understand all that is going on, but bits and pieces are starting to come together here and there for me :)
Very interesting, though I think there's an error in the formula for P(Attacker wins) given Attacker mined previous block.
The correct formula is: 1 - (1 - Z)*exp(-Z*X/600)
Consider C as the random variable for time of next block in the attack scenario (i.e., X seconds of Attacker mining solo, followed by all miners competing should process go past X seconds). Then we have:
P(A wins) = P(A wins | C <= X)*P(C<=X) + P(A wins|C>X)*P(C>X)
Which simplifies to above formula.
The solid lines are the corrected values, and dashed are original:
In particular, the needed delay to effectively double hash for slow blocks for the given scenarios changes to:
1% attacker - 10 minutes (instead of 7)
5% attacker - 11 minutes (instead of 8)
10% attacker - 12 minutes (instead of 9)
20% attacker - 14 minutes (instead of 12)
Please, double-check my math, of course.
#Bitcoin is open doors code 🥁🥁
Definitely far prefer original ones
Never been nearly this blatant in my memory. Oh whelp
This is AI right.?..
