try to create pressure by suspending money withdrawals
until the TCP/IP protocol is changed to match their preferences.
Best regards,
Isidor Zeuner
--
Managing the Performance of Cloud-Based Applications
Take advantage
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
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
quote:
On 6/16/14, Mike Hearn m...@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
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),
quote:
[...]
On 4/24/14, Chris Pacia ctpa...@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
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
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
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
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
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
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
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
[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
[...]
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 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
[...]
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.
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,
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
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
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
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
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
23 matches
Mail list logo
