<unnamed>

Public Key

npub1wz2sm8h4ylh9dn28688vjzwrmhaxnh3jl04p8jk3qeq7umwf8cus72jvxz

Profile Code

nprofile1qqs8p9gdnm6j0mjke4rarnkfp8pam7nfmce0h6snetgsvs0wdhynuwgpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsjjjc7u

Publishing to

relay.damus.io

nos.lol

Last Notes

2023-06-07 17:28:38 CEST

- 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 17:27:33 CEST

- 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 17:23:01 CEST

- 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 17:13:34 CEST

- 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