Zooko Wilcox-O'Hearn [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2012-02-29 to 2016-01-12
💬 Posted a total of 3 messages
📚 Participated in the following categories: Bitcoin-development, bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 17:47:48

- reply

📅 Original date posted:2016-01-12
📝 Original message:Folks:
I don't fully understand this thread, but it sounds like to me it
might be omitting consideration of multi-target attacks. For example,
Tier Nolan's attack
(http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012230.html),
which seems to be the best attack on this thread, seems to start with
one specific public key of an intended victim, but if the attacker is
happy to find a collision with *any* one out of a large number of
potential victims, he gets an advantage proportional to the number of
potential victims.
So it would be wise, in addition to the kind of analysis already done
on this thread (which appears to have already settled at "Yes, we need
> 80-bit security."), to make a nice optimistic estimate of how many
public keys we could eventually have in use. 2⁴⁰? 2⁵⁰? Or maybe be
*very* optimistic, with some added IoT [*] goodness, and budget for
2⁶⁰?
Then we need to budget that many more bits of security to keep the
future attacker's chances of success low enough that the attacker will
never succeed. (Assuming that's our requirement.)
You might enjoy this recent blog post by DJB, legendary cryptographer
who works in this niche of cryptography as well as several other
niches:
http://blog.cr.yp.to/20151120-batchattacks.html
It has some interesting philosophical musings about the "Attacker
Economist" approach. (N.B. My respect for DJB's accomplishments is
tremendous, but that doesn't mean I automatically agree with
everything he says. I haven't made up my mind what I think about this
particular philosophical argument.)
Sincerely,
Zooko
[*] The Internet of Targets

- reply

- reply

- reply

- reply

📅 Original date posted:2012-05-26
📝 Original message:For what it is worth, I question whether this is a problem. Or, I
guess I question whether the best solution to it isn't for people to
start including more transaction fees. In fact, I'm not entirely sure
that this problem doesn't actually *encourage* people to that
solution, which would be very good if true.
I would be more comfortable if the reward for mining were more
commensurate with the value it provides. Ultimately, of course, that
means that each transaction fee would have to be more of a proportion
of the value *to the spender* of that transaction being included in
the blockchain.
(Aside: in order to convey to outsiders that miners are providing a
useful service rather than gaining undeserved reward for wasting
electricity, I refer to them as "distributed transaction verification
servers" rather than "miners" whenever possible.)
I'm pretty sure that — assuming there isn't some Bitcoin-killing
disaster — transaction fees will eventually rise, but sooner might be
better, especially with the first coinbase-halving looming.
Perhaps people will be motivated to include transaction fees if they
know that some miners don't bother to validate their transactions and
others do. They may feel motivated to reward the miners that are
serving them and punish the ones that are not. (Note: this wouldn't be
a valid strategy on their part from a strictly game-theoretic
perspective, but if they act on those motivations, then I don't care
if it was rational or not.)
Also, they may decide that they want to counteract the added delay
which those no-transactions miners are adding to *all* transactions
(with or without fee), by putting a fee on their transactions in order
to make them take less long when they are processed by a miner which
does process (some) transactions.
Already this visualization, which I typically glance at a few times a
day, usually shows a good separation with fee-included transactions
sometimes doing much better than (some) free transactions:
http://bitcoinstats.org/
However, this graph shows that the aggregate reward to the miners for
processing transaction is minimal:
http://blockchain.info/charts/transaction-fees?timespan=60days&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address=
You can see from the first visualization (assuming it is showing the
typical pattern that I've seen) how you risk greater delay by sending
your transaction without fees. The no-transactions miners push *all*
transactions, fee or no-fee to the right. This may incentivize more
people to change their transactions from red diamonds into blue
circles, in order to move their transactions further to the left, even
though the no-transactions miners are not currently discriminating
among the two types.
Therefore, the presence of those miners may help push the aggregate
fees in that latter graph up, which is something I would very much
like to see.
Regards,
Zooko

2023-06-07 10:10:05

- reply

2023-06-07 03:09:49

- reply

📅 Original date posted:2012-02-28
📝 Original message:Could you spell out the attack explicitly? Presumably there aren't a
lot of people with the "malice energy" to perform the attack but not
to figure it out for themselves. I, however, have the "niceness
energy" to think about it for a few minutes but not to figure it out
for myself. If in your opinion it is realistically dangerous to post
it publicly, would you be so kind as to include me in the private
sharing of the explanation?
By the way, I found a couple of cases of slightly bad handling of
merkle trees when I inspected the code (v0.4) that was, I'm 99% sure,
not exploitable. I never got around to reporting it yet. I'm sorry
about that. My discoveries might interact with the one you're talking
about here. I should definitely explain mine to y'all soon. (Possibly
in private for the first pass, in case it is more exploitable than I
thought, or has become exploitable since v0.4.)
I showed it to a couple of other people at the time who helped me make
sure that it wasn't exploitable.
I'll make time to explain what I found within a week.
Regards,
Zooko

2023-06-07 03:09:49

- reply