Re: [Bitcoin-development] MtGox blames bitcoin

2014-02-10 Thread Isidor Zeuner

 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

--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Why are we bleeding nodes?

2014-05-20 Thread Isidor Zeuner
 
  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

--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Proposals for improving Bitcoin mining decentralization

2014-06-17 Thread Isidor Zeuner
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 r...@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

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing  Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension

2014-06-17 Thread Isidor Zeuner
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 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

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing  Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension

2014-06-17 Thread Isidor Zeuner
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

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing  Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] 0 confirmation txs using replace-by-fee and game theory

2014-06-18 Thread Isidor Zeuner
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 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

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing  Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Bitcoin Protocol Specification

2014-07-02 Thread Isidor Zeuner
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

--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Proposal: PoW-based throttling of addresses (was: Outbound connections rotation)

2014-08-20 Thread Isidor Zeuner
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

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Proposal: PoW-based throttling of addresses (was: Outbound connections rotation)

2014-08-23 Thread Isidor Zeuner
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

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Proposal: PoW-based throttling of addresses (was: Outbound connections rotation)

2014-11-13 Thread Isidor Zeuner
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 

Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper

2014-11-26 Thread Isidor Zeuner
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

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Proposal: PoW-based throttling of addresses (was: Outbound connections rotation)

2014-11-26 Thread Isidor Zeuner
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. 

Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper

2014-12-01 Thread Isidor Zeuner
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

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper

2014-12-08 Thread Isidor Zeuner
 
  [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

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper

2014-12-11 Thread Isidor Zeuner
[...]
 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

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain

2014-12-11 Thread Isidor Zeuner
[...]
 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

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper

2014-12-15 Thread Isidor Zeuner
[...]
  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

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain

2014-12-15 Thread Isidor Zeuner
 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

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] determining change addresses using the least significant digits

2015-02-04 Thread Isidor Zeuner
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

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain

2015-02-04 Thread Isidor Zeuner
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

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper

2015-01-21 Thread Isidor Zeuner
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

--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?

2015-01-24 Thread Isidor Zeuner
 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

--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?

2015-03-14 Thread Isidor Zeuner
 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

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development