Zawy [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2018-08-29 to 2019-05-18
💬 Posted a total of 4 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 18:18:06

- reply

📅 Original date posted:2019-05-18
📝 Original message:If MAX_FUTURE_BLOCK_TIME in chain.h is set smaller than
DEFAULT_MAX_TIME_ADJUSTMENT in timedata.h, the POW security can be
undermined by a 33% Sybil attack on the nodes. Blocks with accurate
timestamps would be rejected which allows various attacks. Code should
reflect a proof of security, so it should be coded as
DEFAULT_MAX_TIME_ADJUSTMENT = MAX_FUTURE_BLOCK_TIME / 2
(or sufficiently commented) otherwise future developers could make a
change that hurts security. "Unintended consequences due to how
disparate code interacts" is the result of code not following a proof
of security. I came across this while trying to "derive" POW security
from within Lamport's 1982 framework. The problem is that POW security
requires clock synchronization. But using median of network time for
it is a consensus mechanism that is subject to Byzantine attacks. So
POW requires an absolute bound on time (enforced by an oracle) that is
at least as stringent as the allowed timestamp variation. The rule
to revert to node time if network time is >70 minutes off is the real
bound that honest nodes can impose unilaterally, limiting the
potential damage of consensus (if MAX_FUTURE_BLOCK_TIME is not too
small). This fail-safe uses node operators as the oracle, who can all
approximately agree as to what time it is without asking each other. A
>50% Sybil attack on nodes fails because an honest new node joining
can unilaterally reject the chain if the current timestamp is not
realistic. Cryptonote appears to have done away with network time
without ill effect. The only other option to "the node operator is the
oracle" is to assume all internal clocks have a max drift, but this
would disconnect timestamps from real time to the extent of that drift
(if I'm reading Halpern, etc 1984 IBM correctly). I'm assuming Mike
Hearn was wrong in saying the centralization of NTP (or GPS) is
acceptable:
https://bitcointalk.org/index.php?topic=10241.msg148084#msg148084
This affects coins who reduced MAX_FUTURE_BLOCK_TIME without either
removing the time consensus mechanism or reducing the
DEFAULT_MAX_TIME_ADJUSTMENT. Many have done this in order to have
faster responding difficulty algorithms, otherwise a large
MAX_FUTURE_BLOCK_TIME allows a sizable manipulation of difficulty.
Therefore, MAX_FUTURE_BLOCK_TIME should itself should be a function of
the size of the difficulty window for proof of security (instead of a
constant). I suspect more constants = less proof of security. For
example
MFBT = WindowTimespan / 10 would limit timestamp manipulation to 10% per window.

2023-06-07 18:18:06

- reply

2023-06-07 18:15:32

- reply

📅 Original date posted:2018-12-05
📝 Original message:It's possible to let the difficulty linearly drop as the solvetime
goes beyond some limit (credit AS). If the limit is greater than any
delay in the past it could be backwards-compatible.
A simple daily-rolling average DA like BCH is probably the best option
if a faster DA is ever needed.
As a point of research interest (not likely to be needed by BTC), I've
taken the first above idea of "intra-block" timestamp-based difficulty
adjustment to the limit and made it symmetrical (higher D for fast
solves) and continuous. The result is a "tightening of the Poisson"
that increases "availability" (predictable solution times) at an
expense in "consistency" (orphans). It requires a very tight future
time limit to reduce timestamp manipulation. My objective was to help
small coins deal with persistent 20x hash rate changes that result in
long delays. About 3 coins have it on testnet.
https://github.com/zawy12/difficulty-algorithms/issues/36

2023-06-07 18:15:32

- reply

2023-06-07 18:14:24

- reply

📅 Original date posted:2018-09-17
📝 Original message:The 51% problem is deep. Any discussion of a solution to it should
begin with a link to an article that shows a profound discovery has
been made. Selfish mining prevention and pollution should be on
bitcoin-discussion, but it appears that list is not active.
The problem with Andrew's idea below is that it is a positive feedback
loop that amplifies oscillations. If h goes up or down due to price
changes or random solvetime variation, then the net reward goes in the
same direction, which motivates miners to cause h to go even further
in the same direction, which is a positive feedback loop until some
limit is reached. To make matters worse, miner profit motivation in
choosing which coin to mine is a non-linear function: a 30% drop in
difficulty (or 30% increase in this reward function) in an alt coin
can cause a 300% increase in hashrate.
Average of 144 past blocks to determine h are needed so that it does
not vary too much. A selfish mine of 72 blocks would result in only a
12.5% loss compared to not using this pro-oscillation function. I've
tried similar reward functions in trying to reduce on-off mining.
There may also be a problem of issuing too many or too few coins,
depending on how fast h rises in the long term.
An alternative is to increase difficulty with this or a similar
function instead of reward. From a miner's perspective, there is not a
difference (they are only interested in the (price+fees)/difficulty
ratio. This would have the same problems.
The problem has been solved to the best of our ability by the Nakamoto
consensus. The math is straightforward, so you can't get around it's
failings unless it's a profound solution or we shift trust to some
place else. Currently we have to choose and trust a small group of
coins (or 1) to be the best choice(s), and to trust that the reward
plus fees we pay for mining (compared to coin value) is enough to
prevent a 51% attack.
> Say p is the peak hashrate for 365 periods (1 year)
> consisting of 144 blocks, h is the hashrate of the last 144 block (1
> day) period, and r is the base subsidy (12.5 BTC currently). You can
> then make the max block reward 0.5 r (1 + h/p). So if hashrate is at
> peak you get the full reward. Otherwise you get less, down to a min of

2023-06-07 18:14:24

- reply

2023-06-07 18:14:10

- reply

📅 Original date posted:2018-08-29
📝 Original message:Rather than restricting every timestamp (or just the 2016*N+1
timestamps) to >= 1+ the previous timestamp as recorded on the
blockchain, the difficulty calculation could have the same restriction
but only in how the timestamps are used. I don't know about backwards
compatibility. Either way, this would also prevent the powLimit
attack that is also capable of getting "unlimited" blocks in less than
4 weeks of > 50% selfish mining. LTC, BCH, and LTC fixed to the
"Zeitgeist" or "timewarp" attack on GeistGeld in 2011 described by
Artforz in different ways, but all are still vulnerable by the
powLimit attack that I described here:
https://github.com/zawy12/difficulty-algorithms/issues/30
Other solutions may not prevent this other attack.

2023-06-07 18:14:10

- reply