> >
> > 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 bandwidt
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, the
quote:
> On 6/16/14, Mike Hearn 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 th
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), me
quote:
[...]
> On 4/24/14, Chris Pacia 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 pref
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
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 differe
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
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 har
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 ca
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 irre
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,
> >
> > [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
[...]
> 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 leverage
[...]
> 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 n
[...]
> > 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 geta
> 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
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 conn
> 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 som
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 th
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
> 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
> specificatio
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 bootstr
e 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
--
Managing
24 matches
Mail list logo
