Isidor Zeuner [ARCHIVE]

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

Public Key

npub1wz2sm8h4ylh9dn28688vjzwrmhaxnh3jl04p8jk3qeq7umwf8cus72jvxz

Profile Code

nprofile1qqs8p9gdnm6j0mjke4rarnkfp8pam7nfmce0h6snetgsvs0wdhynuwg6jyzq3

Author Public Key

npub1wz2sm8h4ylh9dn28688vjzwrmhaxnh3jl04p8jk3qeq7umwf8cus72jvxz

Show more details

Last Notes

2023-06-07 17:40:40

- reply

📅 Original date posted:2015-09-20
📝 Original message:Hi there,
replies in-line:
[...]
> 4. Do you ever stop and think: How much *money* was spent for everyone
> to travel to Montreal, stay at their hotels, and to rent the conference
> venue and broadcasting accommodations?
Not to mention that trying to solve a global issue with a conference
local to Montreal is a good example for _centralizing_ Bitcoin...
[...]
> More details are on the project page ( http://bitcoinblocksize.com/ ),
> some technical details are in the Github README.
>
I agree that letting the market decide is the way to go. But I
don't understand why we would want to have yet another
(side-)chain because of that. The market can already decide at the
point where _every_ Bitcoin user starts to discriminate the Bitcoins
he accepts between the client versions of the blocks where the
Bitcoins come from (and the corresponding BIPs where the version
numbers relate to). If a miner decides to follow a particular block
size policy against the will of the community, the market could
quickly rectify it when the miner realizes that no one accepts the
resulting coins anymore, leading to financial loss for the miner.
Best regards,
Isidor

2023-06-07 15:32:06

- reply

📅 Original date posted:2015-03-14
📝 Original message:> That was essentially what we did in the end, we replaced the network
> identifier ("main"/"test") with the genesis block hash. The result is
> never going to accidentally work with Bitcoin Core (nor vice-versa), but
> is readily extensible to any other altcoins that want to use the
> specification without requiring any sort of central registry.
>
Interesting approach, and I also think that requiring a central
registry would be potentially harmful.
However, I think it might not be adequate to think of the network
identifier as being congruent with the genesis block hash. In the
theoretical case of the blockchain being continued on two forked
chains (with two communities which prefer one of the chains each),
clients would not be prevented from interpreting messages on the wrong
chain.
Best regards,
Isidor

2023-06-07 15:29:34

- reply

📅 Original date posted:2015-02-04
📝 Original message:Hi there,
traditionally, the Bitcoin client strives to hide which output
addresses are change addresses going back to the payer. However,
especially with today's dynamically calculated miner fees, this
may often be ineffective:
A user sending a payment using the Bitcoin client will usually enter
the payment amount only up to the number of digits which are
considered to be significant enough. So, the least significant digits
will often be zero for the payment. With dynamically calculated miner
fees, this will often not be the case for the change amount, making it
easy for an observer to classify the output addresses.
A possible approach to handle this issue would be to add a randomized
offset amount to the payment amount. This offset amount can be small
in comparison to the payment amount.
Any thoughts?
Best regards,
Isidor

2023-06-07 15:29:34

- reply

📅 Original date posted:2015-02-04
📝 Original message:Hi there,
comments in-line:
> > I later wrote up the idea in the context of adding Zerocoin to
> > Bitcoin:
> >
> > http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02472.html
> >
For the sake of maximum clarity with respect to modelling the value of
a Bitcoin, I don't think that approaches which change the number
of coins that can possibly be circulated should be encouraged.
So, I like the idea of having the "sacrificed" coins appearing in the
mining fees in a future block. But what is meant with OP_DEPTH in this
context? From what I read, this operation just manipulates the stack
size when evaluating the script, so I don't see how it would
affect miner incentives.
Best regards,
Isidor

2023-06-07 15:29:00

- reply

📅 Original date posted:2015-01-21
📝 Original message:Hi there,
some thoughts in-line:
> >
> > Finally, distributors of consumer wallets can use this research in
> > order to distribute their wallet with policies which may be less prone
> > to Tor-specific attacks. Or leave this out altogether if their
> > audience has different expectations for connecting to Bitcoin.
> >
>
> Sure. I guess there will be wallets for all kinds of people in future,
> sharing a common core that they can customise (this is certainly the vision
> and general direction for bitcoinj, and it's working out OK).
>
> To clarify, my comments above were for mainstream granny-focused wallets.
> Wallets designed for crypto geeks can and should expose all the knobs to
> let people run wild.
>
I hear that. But I don't see why mainstream wallets and wallets
designed for crypto research should not share a common core. Nor do I
understand why having a common core for different types of wallets
should be reserved for BitcoinJ.
When Bitcoin was pretty new, having a less customizable core did
probably have more of a merit in order to achieve network stability
through monoculture. But as of today, Bitcoin has proven itself as
being capable of allowing a variety of client application to run on
the network, so why should the reference implementation not reflect
this kind of diversity? The policy the mainstream distribution imposes
upon the core can still be rather restrictive.
> One possible direction to go is to use Tor for writing to the network and
> use general link encryption and better Bloom filtering for reading it. Thus
> new transactions would pop out of Tor exits, but there isn't much they can
> do that's malicious there except mutate them or block them entirely. If you
> insert the same transaction into the P2P network via say 10 randomly chosen
> exits, the worst a malicious mutator can do is race the real transaction
> and that's no different to a malicious P2P node. Even in a world where an
> attacker has DoS-banned a lot of nodes and now controls your TX submission
> path entirely, it's hard to see how it helps them.
>
It might deserve some research in order to determine how Tor's
privacy guarantees might be impacted if we allow attackers to mess
around with exit node choices in a rather predictable and low-cost
manner. Unfortunately, I can't think of another (non-Bitcoin)
application which puts Tor to a similar test.
> The nice thing about the above approach is that it solves the latency
> problems. Startup speed is really an issue for reading from the network:
> just syncing the block chain is already enough of a speed hit without
> adding consensus sync as well. But if you're syncing the block chain via
> the clearnet you can connect to Tor in parallel so that by the time the
> user has scanned a QR code, verified the details on the screen and then
> pressed the Pay button, you have a warm connection and can upload the TX
> through that. It reduces the level of startup time optimisation needed,
> although Tor consensus download is still too slow even to race a QR code
> scan at the moment. I think tuning the consensus caching process and
> switching to a fresh one on the fly might be the way to go.
>
I do agree that hybrid clearnet/Tor approaches come with interesting
performance properties.
> When BIP70 is in use, you wouldn't write the tx to the network yourself but
> you could download the PaymentRequest and upload the Payment message via an
> SSLd Tor connection to the merchant. Then malicious exits can only DoS you
> but not do anything else so there's no need for multiple exit paths
> simultaneously.
>
BIP70 is interesting, indeed, although I still fail to understand why
(according to the specs I saw) the PaymentRequest message is signed,
but not the Payment message.
But in context of the discussed protocol issues, I think it just moves
the issue from the payer to the payee, so it may or may not partially
relieve network-related issues, depending on the usage scenario.
Best regards,
Isidor

2023-06-07 15:28:38

- reply

📅 Original date posted:2015-01-24
📝 Original message:> For what it's worth, there was consideration of replacing protocol
> buffers when modifying BIP70 to function with the altcoin I work on
> (changes were required anyway in eliminate any risk that payment
> requests could not be accidentally applied to the wrong blockchain).
Why not serialize some kind of blockchain identifier with the
messages? Arbitrarily deviating from a given design choice just for
the sake of doing it differently may serve the goal of creating more
overall code diversity, but would not necessarily serve the quality of
the blockchain network where it is done for.
Best regards,
Isidor

2023-06-07 15:27:47

- reply

📅 Original date posted:2014-12-11
📝 Original message:[...]
> The Bitcoin miner will include burn transactions because they offer
> Bitcoin fees. Bitcoin miner can not selectively block side chains
> since the hashes associated with the burn do not disclose which side
> chain or other project they are for. Here you have a “merged
> mining” that does not need Bitcoin miner support or even consent.
>
Miners might decide to block all burn transactions, and other nodes
might decide to stop relaying them. This may be considered as
preferable by all participants who do not want to add more potential
for deflation.
Best regards,
Isidor

2023-06-07 15:27:46

- reply

📅 Original date posted:2014-12-15
📝 Original message:> The goal is to have an opportunity cost to breaking the rules.
>
> Proof of Burn is a real cost for following the rules.
>
For every participant who could try to decide about the adequateness
of the cost, no direct effect comes from the difference between Proof
of Burn, and approaches which keep the Bitcoins inside the set of
outputs that can still participate. So, any notion which
differentiates with respect to this must make some assumption about
what defines the interest of the Bitcoin nodes as a community.
Best regards,
Isidor

2023-06-07 15:27:40

- reply

📅 Original date posted:2014-12-15
📝 Original message:[...]
> > I'm confused by this, I run quite a few nodes exclusively on tor and
> > chart their connectivity and have seen no such connection dropping
> > behaviour.
>
> In my experience the problem has always been getting bootstrapped.
> Most nodes hardly give any hidden service nodes in their getaddr.
> (this has been improved in master by including a set of hidden service
> seed nodes)
> But this assumes -onlynet=tor. Tor with exit nodes should be less
> problematic, unless someone managed to DoSban all the exit nodes as
> described in the paper (but I've never seen such an attack myself).
>
When refering to "getting bootstrapped", do you only mean collecting
node addresses, or also syncing blocks?
If you're saying the drops in connection counts are likely to be
not caused by a DoSban attack on the exit nodes, what could be other
reasons to look into?
> > Can you tell me more about how you measured this?
> >
> > [As an aside I agree that there are lots of things to improve here,
> > but the fact that users can in theory be forced off of tor via DOS
> > attacks is not immediately concerning to me because its a conscious
> > choice users would make to abandon their privacy (and the behaviour of
> > the system here is known and intentional). There are other mechanisms
> > available for people to relay their transactions than connecting
> > directly to the bitcoin network; so their choice isn't just abandon
> > privacy or don't use bitcoin at all.]
>
> Right, there's something to be said for splitting your own transaction
> submission from normal P2P networking and transaction relay.
> (esp for non-SPV wallets which don't inherently leak any information
> about their addresses)
>
> There was a pull request about this for Bitcoin Core one, maybe I
> closed it unfairly https://github.com/bitcoin/bitcoin/issues/4564 .
>
Great! I find it very interesting to research options for splitting
communication between Tor and non-Tor as long as the introduced
information leakage between both connection methods can be proved to
be nonexistent or negligible.
In the case of Bitcoin, this makes me wonder about an attack that
could look approximately like this:
* Node A connects to Bitcoin using Tor (for submitting transactions)
and IPv4 (for all other communication).
* Node B strives for direct IPv4 connections with node A
* Node B uses the direct IPv4 connections in order to supply Node A
with additional peer addresses not supplied to any other nodes
* Node B observes these additional peer addresses
For transactions submitted to the additional peer addresses supplied
by node B, how to prevent that the probability of these originating
from node A is higher than for originating from other nodes?
For handling block propagation using non-Tor connections, it's
probably harder to create information leaks, as the logic for handling
disagreement about blocks is pretty well-researched, meaning that
it's less important where the blocks come from.
Best regards,
Isidor

2023-06-07 15:27:39

- reply

📅 Original date posted:2014-12-08
📝 Original message:> >
> > [As an aside I agree that there are lots of things to improve here,
> > but the fact that users can in theory be forced off of tor via DOS
> > attacks is not immediately concerning to me because its a conscious
> > choice users would make to abandon their privacy
>
>
> Bitcoin already has a large population of users who have little or no
> technical skill, it wouldn't surprise me at all if it was found to be the
> clear majority by now. Assuming success and growth in future, very few
> users will make any decisions at all about their privacy, they will just
> accept the defaults. In such a world no consumer wallet is going to
> directly expose Tor to end users - if used at all it'll just be used behind
> the scenes. So automated fallback or control over exits would be a concern
> for such wallets.
>
In order to get more synergy between Bitcoin users of varying skill
levels, my suggestion would be a cleaner separation between technical
mechanisms and policies (possibly suitable for users without technical
skills).
Core development would mean providing suitable mechanisms by which it
is possible to run Bitcoin on different constraints. This may include
ways to handle attacks specific to the Tor/Bitcoin combination.
People who like to research what is possible with the protocol can
then experiment on how these mechanisms can be used in order to
mitigate these attacks.
Finally, distributors of consumer wallets can use this research in
order to distribute their wallet with policies which may be less prone
to Tor-specific attacks. Or leave this out altogether if their
audience has different expectations for connecting to Bitcoin.
The tricky part is probably to figure out what is the greatest common
denominator of what keeps Bitcoin stable and running while still
leaving room for customized policies. But I think that separating
concerns like this is better than letting a debate about how to
mitigate certain Tor-related attacks evolve towards a debate about Tor
or not Tor.
> My gut feeling about this stuff has changed over time. I don't think it'd
> be a great idea to tie Bitcoin to Tor too deeply, convenient though its
> infrastructure is. Most apps don't need a whole lot of onion routing - a
> small amount built in to the p2p layer would be sufficient. Tor is huge,
> complicated and could be a liability in future.
>
I think it would be very interesting to explore alternatives for
Tor. But at this point, completely abandoning Tor would mean that
users either have to agree to have their transactions correlated to
their IP address, or to trust their transactions to a third party
where they are not subject to the security guarantees Bitcoin's
logic can provide anymore. In my opinion, it's a rather huge
sacrifice.
What I find interesting, however, is that a lot of suggestions I see
with respect to attacks related to Tor/Bitcoin (including my own)
involve some kind of extra effort required for Tor users on Bitcoin in
order to protect themselves against these attacks. So, it may be
interesting to explore if it is viable to think of Tor's privacy
guarantees as coming for free. Going from there, if it cannot be
guaranteed to work completely for free, the question would be to what
extent the required extra effort should be a shared effort of the
network, and to what extent users requiring the improved privacy
should use their own resources in order to make it possible.
Best regards,
Isidor

2023-06-07 15:27:39

- reply

📅 Original date posted:2014-12-11
📝 Original message:[...]
> And, on the flip side if the host is persistently behind tor, even
> with some watermarkable behaviour, their privacy is protected. So
> making sure that hosts can continually use tor (or similar systems)
> should be the higher priority. (And, of course, not reimplementing
> tor leverages the millions of dollars of investment and dozens of
> subject matter experts working on that system).
>
Reimplementing Tor would not only mean to lose all the investment that
ran into Tor, but also to lose a large user base. We can see this with
TorCoin. Still, the fact that Bitcoin is a use case for Tor which
measurably shows some limits where it is not fully clear if Tor or
Bitcoin is to be blamed does not only mean that both projects may
have to evolve in order to properly solve the issue, but also that the
means of interfacing between both projects may have to be
extended. Ideally, in a way which does not require to run a separate
Tor and/or Bitcoin network in order to work, but which will be generic
enough to satisfy both sides' need to still work in a standalone
manner.
But I do see huge merit in exploring better ways of synergy between
the projects. For example, Tor's hardcoded circuit length may be
considered as a hack which was only necessary due to the lack of a
suitable resource compensation mechanism. Which is something that is
available with Bitcoin.
Best regards,
Isidor

2023-06-07 15:27:38

- reply

📅 Original date posted:2014-12-01
📝 Original message:Hi Gregory,
response below quote:
> > Since this attack vector has been discussed, I started making some
> > measurements on how effective it is to connect to Bitcoin using Tor,
> > and I found that the number of connections dropping to near-zero is
> > a situation which occurs rather frequently, which suggests that there
> > is still room to improve on the DoS handling.
>
> I'm confused by this, I run quite a few nodes exclusively on tor and
> chart their connectivity and have seen no such connection dropping
> behaviour.
>
> Can you tell me more about how you measured this?
>
When you say "running exclusively on Tor", what do you mean exactly?
Do you also connect or allow connections through hidden services?
I made outbound connections through Tor exit points the only way to
connect to Bitcoin, and increased the number of allowed outbound
connection in order to get more meaningful values.
Lately, I could see unusual behaviour at:
* 2014-11-28 13:14 UTC
* 2014-11-25 07:32 UTC
* 2014-11-24 13:06 UTC
Anything I should look into?
> [As an aside I agree that there are lots of things to improve here,
> but the fact that users can in theory be forced off of tor via DOS
> attacks is not immediately concerning to me because its a conscious
> choice users would make to abandon their privacy (and the behaviour of
> the system here is known and intentional). There are other mechanisms
> available for people to relay their transactions than connecting
> directly to the bitcoin network; so their choice isn't just abandon
> privacy or don't use bitcoin at all.]
>
I think this issue is more important than it seems.
Firstly, when running Tor-only, there are still attack vectors which
make use of the DoS protection deficiencies.
Secondly, if we tell people not to connect directly if they want
privacy, how do we ensure that these indirect methods will not come
with implications for their privacy?
Best regards,
Isidor

2023-06-07 15:27:33

- reply

📅 Original date posted:2014-11-27
📝 Original message:Hello there,
quote:
> Please see also the following:
>
> https://cpunks.org//pipermail/cypherpunks/2014-November/005971.html
>
I agree about the severity of the Tor/Bitcoin issue, but I see no
point in bashing Bitcoin's financial privacy characteristics as
the linked pages seem to do.
Bitcoin can be useful as a part of a strategy to improve on privacy,
but it does not intend to be a run-and-forget solution for doing so.
A lot of issues found in this context can actually be traced back to
Tor's characteristics already known before. It's just that
Bitcoin makes Tor's deficiencies more measurable - before Bitcoin,
those interested in researching how Tor performs in an automated
context where a much smaller community. In the end, I guess both
projects can benefit from the research we can do now.
> Respect,
>
> - -Odinn
>
> Jeff Garzik:
> > I don't recall being contacted directly, but the attack has been
> > discussed. It relies on a number of conditions. For example, if
> > you are over Tor, they try to kick the machine off Tor, _assuming_
> > that it will fall back to non-Tor. That's only true for dual stack
> > nodes, which are not really 100% anonymous anyway -- you're
> > operating from your public IP anyway.
> >
Generally, it cannot be said that the attack vector described here is
irrelevant for non-dual-stack nodes. An attacker might not be able to
collect IP addresses of Tor-only nodes, but he can try to kick the
users from all Tor exit nodes he does not control, and proceed with
other attacks when a large number of Tor-only users connect through
his Tor exit node(s).
Since this attack vector has been discussed, I started making some
measurements on how effective it is to connect to Bitcoin using Tor,
and I found that the number of connections dropping to near-zero is
a situation which occurs rather frequently, which suggests that there
is still room to improve on the DoS handling.
Best regards,
Isidor

2023-06-07 15:27:26

- reply

📅 Original date posted:2014-11-27
📝 Original message:Hi Mike,
thanks for your assessment.
Please find my replies in-line:
> DKIM is hardly a PoW; signing is cheap and gets cheaper all the
> time. I used to work in the email business and big bulk mailers all spent
> far more CPU time on other aspects of their business, the overhead of
> DKIM is irrelevant.
>
Well, as long as bulk mailing companies run around investing into
per-destination DKIM toggling, stating that they want to cut down CPU
usage due to crypto processing, I tend to believe that it can have an
important impact depending on the setup. Of course, I cannot rule out
the possibility that they would be better off investing into profiling
CPU usage, and/or exploring a higher ROI possibly coming from using
more CPU time on other processing. I see no point neglecting an issue
just because there are business models where it is irrelevant,
though.
> PoW didn't work in the anti spam world because it (amongst other
> problems) mixes up bulk mail and spam, which are not the same
> thing. Very common conceptual error though.
>
I did not say so, either. But bulk mailing and e-mail spam are not
orthogonal with respect to the technical characteristics that make
them possible. And nor are DKIM and PoW/hash-cash fully orthogonal.
I like the objections you raised. Avoiding DKIM because of the CPU
costs involved might be as groundless as stating "we don't use
HTTPS in order to save CPU time". Still, these substantiations can be
found in the wild, and they won't disappear because we discuss
them here on a theoretical level.
If you assume conceptual errors, though, I would suggest we discuss
the e-mail topic off-list, though. I simplify things a bit in order to
not bore the group with too much text about non-Bitcoin stuff, but
this does not mean that I'm not familiar with, or am not open for
discussing the subtle differences of different approaches that have
been researched in the e-mail business.
>
>> humans also don't care if their patience is put to the test by
>> having to wait until one Tor exit node is finally unbanned, or by
>> waiting for the connection PoW to finish because it temporarily got
>> harder due to an attack.
>>
>
> They don't? This is news to me. Humans always care. One of the
> surest ways to hurt your online business is to have a slow website
> because lots of users will give up rather than tolerate a few seconds
> of latency. At Google we actually had formulas that could relate a
> change in web search latency to revenue impact.
>
You might want to re-read my statement more carefully. I did not say
they don't care about delays, but I do say that they don't
care where the delays come from.
It is a known fact that Google will also penalize web sites which have
high latencies, so the top results appear as being also of technical
quality. But neither the users nor Google will care if the web site is
slow because the site owner did not allocate proper resources for
running the frontend quickly, or if the database server is making
things slow.
> So humans very much care! I actually doubt that any reasonable
> mobile wallet will use the new Tor support bitcoinj by default, for
> example, because it imposes quite some startup cost when the
> downloaded consensus isn't fresh, and slow startup is painful. It
> could be optimised but nobody has done that. For long running desktop
> wallets where startup time can be amortised over hours or days, I
> guess it makes more sense.
>
I agree that improving on the performance of the consensus
bootstrapping logic is an interesting topic.
> I agree that PoW tokens might make sense as a last resort if nodes
> can't even put a connection at the bottom of a priority queue and
> you're right that it may be a useful tool in a shared
> toolbox. However if we reach the point where users are all being PoWd
> then we're already pretty hosed and it's probably close to
> game over :(
>
I don't think this was ever about _all_ IPs suffering from DoS
measures. But I do think that Bitcoin will already suffer if we get to
a point where it is practically useless when being used over Tor, or
where this is only possible by immediately sacrificing the privacy
improvement Tor introduces.
>> I'd say, better have a few Tor-based users realize that they
>> should look for a fixed update because their client has to do PoW
>> for connecting, rather than having all Tor-based users locked out.
>>
>
> I think Tor is a separate issue. If an attacker wants to either
> force all users off Tor, or force them via a handful of exits, then
> this attack is quite detectable already and wallets could already
> decide to simply give up on Tor at that point automatically. No PoW
> needed. Well, ideally, nodes would disconnect a banned IP with some
> kind of notice saying why it was banned, but that's a small
> improvement.
>
I fully agree. A ban notice could also make it easier to track down
DoS handling issues triggered by incompatible updates, and possibly
make it harder for someone to issue bans for malicious reasons without
being noticed. Also, I see it as an important step towards a modern
security policy, because it would emphasize that the Bitcoin network
can be kept secure with minimum obscurity.
>> Still, users should be notified that something is unusual.
>>
>
> If we're talking mainstream success then users by and large do
> not care about technical mumbo jumbo like peer to peer networks or Tor
> ("that's the thing drug dealers and pedos use???"). They just want
> the damn thing to work reliably. So notifying them is unhelpful -
> it's not actionable. They would just see a message like
>
> "The wizzle sprocket is kaput - keep working? YES NO"
>
> and then everyone presses yes.
>
As you say, the mainstream user won't care about technical mumbo
jumbo like Tor, so he won't be likely to run Bitcoin over Tor. So,
the most likely cases where he would encounter the notification would
be:
* incompatible update
* his machine / network is compromised and connects to Bitcoin,
triggering DoS measures
In both cases, he would consider it as important to take action, so
even a scary notification might be the way to go.
The non-mainstream user who is willing to dive into the technical
details of running Bitcoin over Tor securely will generally be more
likely to be able to make more differentiated decisions about such an
anomaly, but I cannot see why we would want him to not have proper
tools to deal with the situation, or not to be informed about
something unusual happening.
> Stuff like Tor plays well in the crypto community but it's very
> hard to actually switch on by default, because it needs to have absolutely
> no cost at all, otherwise you'll just annoy the vast majority who
> don't want to pay for very abstract and hard to quantify privacy
> benefits.
>
Agreed. But as outlined above, those who enable it on purpose will
benefit, and those who don't also don't have a
disadvantage. Am I missing something?
> So I think it's worth considering the DoS problem and Tor
> somewhat separately, even though they're related. The solution to
> a crafty privacy-attacking DoS that tries to make exits useless is
> don't use Tor at all. The solution to "the entire Bitcoin network
> is under attack" is much harder.
Indeed. For the issues we're seeing, Tor can actually be regarded
to be at fault to some extent. So the Tor development might also
benefit from these things being researched. But I see no reason to
sacrifice the possibility to use Tor on Bitcoin properly at this
point.
I also agree that a solution which improves the situation of Tor nodes
must not make it easier to attack the entire Bitcoin network. I'm
just not seeing why this would be the case for the approach I
outlined. I actually think that having multiple values to tune in
order to throttle unwanted behaviour on the network might even improve
on Bitcoin's robustness as a whole, because it might enable better
targeted moves against other (non-Tor-related) threats. How do we know
if the most dangerous attacker Bitcoin will face has more resources
with respect to IP addresses, or CPU time?
> It's unclear to me we can ever
> solve it convincingly - banks don't connect together using private
> networks in which anonymity is forbidden because they're
> stupid. They do it because it solves DoS attacks in one solid move and
> they feel it's worth the high cost.
Well, banks did not even consider inventing something like Bitcoin
because what they have works well enough for their purposes. Still,
for some reasons, there are a lot of people interested in Bitcoin. I
would argue that it is because it tried to solve some things private
banking networks did not, so we might consider not only keeping
Bitcoin attractive for those who consider it as a badly implemented
form of what banking networks already provide.
Kind regards,
Isidor

2023-06-07 15:27:26

- reply

📅 Original date posted:2014-11-13
📝 Original message:Hi Mike, hi Ivan, hi all,
>
> >
> > Since when? This has been a recognized approach since people called it
> > "hashcash" ([1] - before cryptocurrencies were even invented).
> >
>
> I only know of one site that worked the way you propose: TicketMaster, a
> long time ago. They used it as a less harsh form of blocking for IPs that
> they strongly suspected were bots, which is what you suggest indeed. But
> 99% of the hard work of that system was in scoring the connections. The
> actual PoW part didn't work that great because bots have much more patience
> than humans do.
>
I think the proposal back then was targeted at e-mail
delivery. Interestingly, one of today's most common approaches
against unsolicited e-mails, DKIM, can also be considered as being a
relative to PoW if we consider that bulk mailer operators don't
like it because of the CPU burden it creates. But with e-mail, people
tend to see it even as an advantage to also have identification of the
participants, so it's no surprise that pure PoW approaches did not
achieve importance.
With cryptocurrencies, it's different. Combating DoS without
creating additional ways to identify users is something where many
interested users can be found.
Humans may have less patience than an attacker who just wants to
achieve his DoS objective in a batch processing manner. But humans
also don't care if their patience is put to the test by having to
wait until one Tor exit node is finally unbanned, or by waiting for
the connection PoW to finish because it temporarily got harder due to
an attack.
No doubt that a dedicated attacker can have an (even big) advantage
resource-wise. But this is no different between the case where both
computing power and the number of Tor exit nodes are the resource to
compete on, and the case where it's just the resource of Tor exit
nodes that gets exhausted. But by giving users the choice of proving
their dedication through a connecting PoW challenge, I would expect
users having more possibilities of finding their way through a
DoS-imposed partial outage. After all, the possibly powerful attacker
has to invest his resources into making all access routes to the
network unusable, while for well-behaved users, every single access
route that still works is useful. Therefore, I think it makes sense to
add more degrees of freedom.
> Other sites also use proofs of work, but they're CAPTCHAs i.e. human PoWs.
> And unfortunately those don't work very well these days either :(
>
None of these measures are perfect. But I think we can achieve a
solution that is good enough. Hopefully without integrating a
centralized captcha provider ;)
>
> > To be clear, I do not propose to have _all_ clients do complicated
> > work. Just those using an address which has been misbehaving.
>
>
> Yes, I understand, but then you're back to scoring clients - the hard part
> - and the only question is do you slow down that client by sticking them at
> the bottom of a work queue or by requiring them to solve a difficult PoW.
> The best approach is the first one because that scales naturally .... you
> don't have to define some notion of misbehaviour, you just prioritise
> amongst clients.
>
On the one hand, I think that to some extent, the work queue based
throttling just moves the problem from making it hard to connect
towards making it hard to do something useful with your connection.
But as I touched above, I see the merit that comes from the PoW-based
approach in allowing well-behaving users to explore multiple axes of
putting effort into connecting. Expanding on this approach, I think
that the work queue based approach and PoW could be combined, leading
to three measures the nodes can use for throttling misbehaving
clients:
* scaling up connection PoW
* throttling the connection on the work queue
* throttling the IP on the work queue
The challenging part would be to properly tune the extent of the three
measures in order to throttle attackers' messages with minimum
impact to well-behaving users.
> The current notion of "misbehaviour" is only somewhat useful. It's easy to
> classify reasonable behaviour as harmful and shoot yourself in the foot. We
> managed this at least once back in 2010 when we actually released a version
> of Bitcoin that interpreted a normal request to serve the block chain as a
> DoS attack! It couldn't serve the chain at all! Additionally many things
> that can be interpreted as an attack like sending a message with a bad
> signature can also be caused just by mistakes, or version skew during
> software upgrades. So it's very tricky to get this right.
>
Sure, but that's a different topic. It may not be even realistic
to have a model which can be reduced to deciding between purposeful
misbehaviour and regular usage. But an attacker who wants to cut off
IPs from the network will always use whatever misbehaviour that leads
to maximum penalty, meaning that it is a decision between not
penalizing at all, or doing so.
> That's important because one quite common way big sites suffer DoS attacks
> is by accidentally having real users create a DoS "attack" by e.g. pushing
> a bad software update, or by having sudden and unexpected press-driven
> growth, etc. You really don't want to force users to sit around waiting and
> wasting battery. It's better to serve as many requests as you can up to
> your absolute limit and try to ensure as many of them as possible are good.
>
I'd say, better have a few Tor-based users realize that they
should look for a fixed update because their client has to do PoW for
connecting, rather than having all Tor-based users locked out.
Still, users should be notified that something is unusual.
>
> > Exactly. Not every user may like to have a cookie by which an observer
> >>
> > might get the chance to even link his connection to his previous
> > connections, thereby allowing the discussed deanonymization technique
> > to get even more effective.
> >
>
> I doubt it matters. Any DoS attack that's powerful enough to use up most of
> the networks resources is probably being driven by a botnet of some kind,
> and *all* legitimate users will lose in an even fight against a botnet.
>
> Cookies can be somewhat anonymized. For example a cookie that is merely a
> signature over a timestamp of some kind (doesn't have to be an secp256k1
> signature) can be normalised to the day or week. So you can prove you've
> been using Bitcoin for say 3 years but it doesn't pin you down precisely.
>
> This isn't perfect: attackers can and do "age" accounts before preparing
> for abuse. Proof of UTXO is another way to rank users. If you're richer
> you're presumably more important for the network to process than poor
> people. However you end up back at a CPU imbalance. PoW can possibly play a
> role here to even it out: the cost of submitting a UTXO proof should be at
> least equal to the cost of verifying the signature, but that is a PoW small
> enough that users would not notice.
>
Both cookies and Proof of UTXO sound like interesting approaches, but
I still see additional possibilities to deduce information about the
user identity here. They could be a nice addition for a better
approach to handle DoS attacks, but I would disagree when it comes to
only providing possibly privacy-weakening approaches.
I'm looking forward to your comments.
Best regards,
Isidor

2023-06-07 15:25:15

- reply

📅 Original date posted:2014-08-23
📝 Original message:Hi Mike,
thanks for your assessment.
Please find my replies in-line:
> >
> > Misbehaving addresses can have their connecting difficulty
> > scaled up, which should make it uneconomic to try to DoS the usage of
> > Tor exit nodes for connecting to Bitcoin.
> >
>
> You can't solve DoS by requiring all clients to do complicated work,
Since when? This has been a recognized approach since people called it
"hashcash" ([1] - before cryptocurrencies were even invented).
I hear your concerns, but even then, I would see the PoW-based
approach as an improvement to today's situations.
To be clear, I do not propose to have _all_ clients do complicated
work. Just those using an address which has been misbehaving. Right
now, they cannot connect at all, no matter how much resources they
dedicate towards doing so.
> all
> that means is that weak clients (like users mobile phones and tablets) are
> successfully DoSd whereas the attackers botnet of stolen computers sit
> there solving PoWs.
>
The way I had it in mind, well-behaved clients on an address used by
attackers would have more effort to connect because of the PoW, but
after that, they can stay connected. The attacker also has to put more
effort into connecting, and after sending malformed messages, gets
disconnected. So, the attacker would have to perform much more PoW
computations in order to keep up his attack.
> The correct way to solve DoS is by having work prioritisation and queueing
> mechanisms, then finding ways to distinguish "good" clients from "bad"
> clients. Doing this whilst preserving privacy is hard. Long term the only
> way to solve it may be to require clients to present some kind of cookie
> during resource exhaustion events that prove they've been around for a
> while, thus allowing them to jump the queue.
>
Exactly. Not every user may like to have a cookie by which an observer
might get the chance to even link his connection to his previous
connections, thereby allowing the discussed deanonymization technique
to get even more effective.
Maybe having both options would be even better: In case of an attack,
those able to solve the anti-DoS PoW can still connect (just maybe
slower). Those who wish to run a weak client can choose to sacrifice
privacy for connectivity and keep a cookie for connecting.
Best regards,
Isidor
[1] http://www.hashcash.org/papers/hashcash.pdf

2023-06-07 15:25:15

- reply

📅 Original date posted:2014-08-20
📝 Original message:Hi there,
quote:
[...]
> If two distinct transactions (with unrelated bitcoin addresses)
> come from the same set of 8 peers, the attacker can conclude that they
> originated from the same user. This gives another method (in addition
> to transaction graph analysis) for an attacker to link different BC
> addresses of the same user.
Using the same set of nodes for posting transactions using unrelated
inputs kind of limits the privacy improvement that can be gained from
using unrelated inputs in the first place.
Similar to how Tor uses different circuits for different hosts to
connect to, it may make more sense to only use the same set of nodes
for posting a subsequent transaction when the input addresses are also
the same.
[...]
> Some details are here: https://www.cryptolux.org/index.php/Bitcoin
>
I also find the topic of banning Tor exit nodes interesting.
I wonder if it makes more sense not to ban IP addresses completely,
but instead to throttle them using a PoW-based access control
scheme. Misbehaving addresses can have their connecting difficulty
scaled up, which should make it uneconomic to try to DoS the usage of
Tor exit nodes for connecting to Bitcoin.
It may also help nodes behind a NAT router if they share their global
IP with misconfigured nodes.
Best regards,
Isidor

2023-06-07 15:23:27

- reply

📅 Original date posted:2014-07-02
📝 Original message:Hello Krzysztof,
[...]
> As before, it can be found under:
>
> http://enetium.com/resources/Bitcoin.pdf
>
> I hope it will prove useful to the community and thank in advance
> for any further improvement proposals.
>
I think it's great work and provides a good reference for those
who want to get some insight into Bitcoin's design.
Have you considered putting the document source under version control,
which may facilitate tracking future protocol improvements in the
document easily?
Best regards,
Isidor

2023-06-07 15:23:06

- reply

📅 Original date posted:2014-06-19
📝 Original message:quote:
[...]
> On 4/24/14, Chris Pacia <ctpacia at gmail.com> wrote:
> > It would work but it's an ugly hack IMO. What do people do if they don't
> > have extra to pay when making a purchase? I have 200 mbtc and want to buy a
> > 200 mbtc phone but I can't because I need 400 mbtc. Sucks for me.
> >
> > I would much prefer the hassle of a green address notary than always having
> > to make sure I have double what I need to make a purchase.
>
> This scheme wouldn't be mandatory. You can still wait for
> confirmations or rely somehow on existing trust instead if that's
> better for you on that situation.
>
Considering hotel or car rental payments where the credit card
processor reserves a higher amount in order to cover risks, it
doesn't seem like anything new or particularly inconvenient that a
payment system may require a larger amount than the final price being
available.
Which brings us to the question: Is it an important characteristic in
a payment system that it is capable of quickly spending your last
penny?
Best regards,
Isidor

2023-06-07 15:23:01

- reply

📅 Original date posted:2014-06-17
📝 Original message:quote:
> https://en.bitcoin.it/wiki/Getblocktemplate is supposed to solve most
> of the pooling-centralization problems. Unfortunately, it is opt-in,
> and GHash.io doesn't support it.
>
> Also most miners don't care and don't do the work to set it up. To do
> transaction inclusion themselves, they'd need to run a full node,
> which is a bit more work and resources than just pointing hashpower at
> a stratum server.
>
> If you figure out a way to make GBT widely used (>50% hashpower), kudos to you.
>
Well, as soon as miners learn about the merits of controlling the
blocks' contents, this issue may get solved by the market pressure
of miners expecting this kind of service from their pool.
I mean, the dev community constantly has some level of disagreement
about the best policies for what to include in blocks. But seen from
the perspective of some Bitcoin business or another, certain policies
might be more preferable. So if miners start to understand that they
could take a stake for their favourite Bitcoin businesses by choosing
a mining pool which employs a preferable transaction inclusion policy,
the question would not anymore be "which pool gives me the most
Bitcoins or the lowest variance, regardless of the technical
background", but "which pools does the best for my Bitcoin economy
needs". And this may be a very economically driven decision by itself,
considering that the exchange rates for Bitcoins depend on Bitcoin
businesses doing well.
If we get to this point with respect to user (miner) education, then
it is probably only a matter of time until people start to find it
cumbersome to mine on a black-box pool and having to manually verify
that they still have an agreeable transaction inclusion policy, when
they can just mine on a GBT pool and configure things in their mining
software.
> On Tue, Jun 17, 2014 at 4:57 AM, Raúl Martínez <rme at i-rme.es> wrote:
[...]
> > We all know the recent news, Ghash pool controlling 51% of the hashrate.
> > While some consider it a threat others think that is not harmful.
> >
> > The thing is that we have to do something to stop this from happening again.
> >
Bear with me, but this piece of rhetorics struck me. Why even mention
those who think it's not harmful, when your next sentence states
that their opinion should be ignored completely?
Best regards,
Isidor
>

2023-06-07 15:22:49

- reply

📅 Original date posted:2014-06-17
📝 Original message:quote:
> On 6/16/14, Mike Hearn <mike at plan99.net> wrote:
> > If they decide to change to something like highest-fee-always-wins, then
> > they (again) centralise things by forcing all instant transactions to pay
> > GreenAddress and its competitors money - much though I like your product
> > Lawrence, let's hope they don't collectively lemming us all off a cliff by
> > doing that ;)
>
> Replace-by-fee doesn't imply the use of green addresses (there's other
> solutions to 0 conf transactions in that context, for example,
> "scorched earth"). And giving up the non-enforceable first-seen
> default mining policy doesn't mean "giving up on the Bitcoin
> experiment" either.
>
If something means "giving up on the Bitcoin experiment", then for
sure it's not one mining policy or another, but the assumption
that we should have one uniform mining policy. If we had a community
where enough miners had their own opinion about the best mining
policy, and expressed it by choosing an appropriate mining pool, then
we would have better decentralized mining based on selfish motives of
the miners, rather than based on an abstract thought of
"centralization is bad, so I will consider how much mining profit
from qualitatively interchangable mining pools I'm willing to
sacrifice in order to ease my centralization fears".
Best regards,
Isidor

2023-06-07 15:22:49

- reply

📅 Original date posted:2014-06-17
📝 Original message:quote:
> Mike Hearn, why don't we just have all nodes report attempted double spends
> through the node network. No need to involve the miners at all really, or
> do your suggestion but also report the double spend attempt. By waiting
> maybe 10-60 seconds (instead of 10 minutes for first conf), merchants can
> be more sure that a double spend attack was not tried. Attacker would have
> to hold back second tx by 10-60 seconds and hope that that second tx (with
> higher fee) get's into a solved block before the first one. This forced
> delay time ought to make the attack less successful (but not impossible).
>
What prevents the following steps from happening:
1. attacker sends first transaction, paying to the merchant
2. merchant waits 10-60 seconds
3. merchant confirms the payment as received
4. attacker sees merchant's confirmation
5. attacker sends double spend
The security improvement seems to be pretty much exactly the chance
that during the 10-60 seconds, a block is solved. Am I missing
something?
Regarding "reporting double spends", this would only help if it comes
with some kind of penalty for the double spend. Now what if the double
spend was not done on malicious motives? Maybe someone posted a
transaction which does not confirm for some reason, and wants to
recover his funds? Should we regard transactions which do not confirm
as forever lost, in order to get to an "every double spend is a
misbehaviour" policy?
Best regards,
Isidor

2023-06-07 15:21:50

- reply

📅 Original date posted:2014-05-20
📝 Original message:> >
> > In my opinion, the number of full nodes doesn't matter (as long as
> > it's enough to satisfy demand by other nodes).
> >
>
> Correct. Still, a high number of nodes has a few other benefits:
>
> 1) The more nodes there are, the cheaper it should be to run each one,
> given that the bandwidth and CPU for serving the chain will be spread over
> more people.
>
> 2) It makes Bitcoin *seem* bigger, more robust and more decentralised,
> because there are more people uniting to run it. So there's a psychological
> benefit.
>
Psychological benefit vs. effective benefit involves the danger of
destroying trust in the Bitcoin network when there are hard facts for
non-robustness while the node number looks big. Therefore, it may make
sense to establish better metrics.
> Also, we don't have a good way to measure capacity vs demand at the moment.
> Whether we have enough capacity is rather a shot in the dark right now.
>
>
> > What matters is how hard it is to run one.
> >
>
> Which is why I'm interested to learn the reason behind the drop. Is it
> insufficient interest, or is running a node too painful?
>
> For this purpose I'd like to exclude people running Bitcoin Core on laptops
> or non-dedicated desktops. I don't think full nodes will ever make sense
> for consumer wallets again, and I see the bleeding off of those people as
> natural and expected (as Satoshi did). But if someone feels it's too hard
> to run on a cheap server then that'd concern me.
>
In my opinion, the characteristic of being able to make use of
non-dedicated nodes should be regarded as an advantage of the Bitcoin
protocol, and not something to get rid of. Nodes being able to
contribute this way may lead to even more robustness than
decentralization alone, as they can do so without exposing a fixed
address which could be attacked.
Best regards,
Isidor

2023-06-07 15:13:34

- reply

📅 Original date posted:2014-02-10
📝 Original message:>
> What is the official response from the Bitcoin Core developers about
> MtGox's assertion that their problems are due to a fault of bitcoin, as
> opposed to a fault of their own?
>
> The technical analysis preluding this mess, was that MtGox was at fault for
> their faulty wallet implementation.
>
I'm not a core developer, but I would certainly hope that those
who have commit access to the Bitcoin repository don't let
themselves be pressured by a company holding back user funds in order
to get a patch included into the Bitcoin source code.
I think this is less a matter of whose fault it is if a company
running a custom wallet implementation has problems peering with a
network mostly running another, community-based wallet
implementation. It is a matter of common sense that it's just not
practical to try to quickly apply an update to a distributed network,
which may possibly cause problems with peering and consensus
finding. When working with a protocol based on mutual agreement of a
large user base, a single entity like MtGox would be better off trying
to have their preferred changes implemented slowly if at all, while
solving their immediate issues on their side. Problems with
transactions being accepted can often be solved by changing the wallet
client's way of peering with other nodes, without changing the
protocol at all.
Thinking this further, I am kind of surprised that something like this
can even become an issue worth discussing. I never heard of a bank
which would try to create pressure by suspending money withdrawals
until the TCP/IP protocol is changed to match their preferences.
Best regards,
Isidor Zeuner

2023-06-07 15:12:09

- reply

📅 Original date posted:2014-01-16
📝 Original message:quote:
> > but then you remove the implication that a node has to give both public
> > and private IPs to a peer. If it's part of a batch of "addr"s, it could be
> > my own hidden service ID, but it could also be one that I learned from
> > someone else and is now propagating, for anyone to bootstrap with Tor
> > hidden service peers if they'd like.
> >
>
> Hmm. So you mean that we pick a set of peers we believe to not be sybils of
> each other, but they might give us hidden services run by other people? I
> need to think about that. If they're getting the hidden services just from
> addr announcements themselves, then you just punt the issue up a layer -
> what stops me generating 10000 hidden service keys that all map to my same
> malicious node, announcing them, and then waiting for the traffic to
> arrive? If clearnet nodes inform of their own hidden service IDs, that
> issue is avoided.
>
Considering that the clearnet sybil protection also relies on scaling
up the resource requirements for an attacker, why not require hidden
service addresses following a certain pattern, like a fixed prefix?
Essentially also a PoW scheme...
> My goal here is not necessarily to hide P2P nodes - we still need lots of
> clearnet P2P nodes for the forseeable future no matter what.
What would you consider as the main merits of clearnet nodes?
Best regards,
Isidor