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

2014-11-27 Thread Mike Hearn

 [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.

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.
--
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-11-27 Thread Wladimir
On Thu, Nov 27, 2014 at 2:22 AM, Gregory Maxwell gmaxw...@gmail.com wrote:
 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.

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).

 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 .

Wladimir

--
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


[Bitcoin-development] bitcoind as a library

2014-11-27 Thread Mem Wallet
Two minor observations:

DecodeBase58Check is listed as inline, but isnt actually inlined in the
header.
This makes it both non-present in libbitcoin_common.a and unavailable
to other code that would use libbitcoin_common.a as a library. (bug?)

In general, the hierarchy of tools is poor/weak. for example base58.h could
be a fairly
independent low level math/string library, but it includes caddress, which
requires chainparams, and makes the whole dependency tree quite involved...


Is there an intention that the various internal libraries could/should
be strengthened and heirachicalized such that they would be suitable for
3rd party development of bitcoin related services and tools, or is that not
a goal, and some other project would have to fill such a role ?
--
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-11-27 Thread Mistr Bigs
I might be mistaken, but it seems to me this paper discusses unintended
ways of obtaining the IP addresses of clients involved in transactions on
the core Bitcoin network.
Tor was mentioned only insofar as it might be one's first thought of how to
mitigate this risk, yet Bitcoin over Tor has its own problems that prevent
this from being effective.
But the primary issues mentioned in the paper are regarding a Bitcoin
node in default operation, no?

In their new study, researchers at the Laboratory of Algorithmics,
Cryptology and Security of the University of Luxembourg have shown that
Bitcoin does not protect user's IP address and that it can be linked to the
user's transactions in real-time.

The basic idea behind these findings is that Bitcoin entry nodes, to which
the user's computer connects in order to make a transaction, form a unique
identifier for the duration of user's session. This unique pattern can be
linked to a user's IP address. Moreover, transactions made during one
session, even those made via unrelated pseudonyms, can be linked together.
With this method, hackers can reveal up to 60 percent of the IP addresses
behind the transactions made over the Bitcoin network.

'This Bitcoin network analysis combined with previous research on
transaction flows shows that the level of anonymity in the Bitcoin network
is quite low,' explains Dr. Alex Biryukov.

M
--
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] bitcoind as a library

2014-11-27 Thread Wladimir
On Thu, Nov 27, 2014 at 5:27 PM, Mem Wallet memwallet.i...@gmail.com wrote:

 Is there an intention that the various internal libraries could/should
 be strengthened and heirachicalized such that they would be suitable for
 3rd party development of bitcoin related services and tools, or is that not
 a goal, and some other project would have to fill such a role ?

The plan is to provide the consensus functionality as a library, the
essential parts that make bitcoin bitcoin.
0.10 will have a basic transaction/script verifier available.
In the version after that, I expect this will be extended to further
utxo set management, but no API has been worked out for that yet.
There are also plans to add a library for transaction signing.

However there is no goal to expose *everything* as a library.
Certainly not wallet- or user interface related functionality.
Specialized utility libraries would fill this purpose better.
See for example https://github.com/bitcoin/libbase58 for base58 processing.

Wladimir

--
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] bitcoind as a library

2014-11-27 Thread odinn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



A recent comment on this (I think)...

https://github.com/bitcoin/bitcoin/issues/4564#issuecomment-49558760

Reflecting on an approach from a different but related project, as a
result of an issue discussion in DW, stealth and coinjoin from that
project were broken out as distinct repositories - see:

https://github.com/darkwallet/stealth.js
and
https://github.com/darkwallet/coinjoin.js

installable using npm


I'm probably missing something here, but it seems to me like breaking
things out as distinct repositories might be a good approach.  The
question is what would be in a distinct repository or repositories?
Currently if someone is looking at core, everything is seen here:
https://github.com/bitcoin/bitcoin/

slips away for holidays




Wladimir:
 On Thu, Nov 27, 2014 at 5:27 PM, Mem Wallet
 memwallet.i...@gmail.com wrote:
 
 Is there an intention that the various internal libraries
 could/should be strengthened and heirachicalized such that they
 would be suitable for 3rd party development of bitcoin related
 services and tools, or is that not a goal, and some other project
 would have to fill such a role ?
 
 The plan is to provide the consensus functionality as a library,
 the essential parts that make bitcoin bitcoin. 0.10 will have a
 basic transaction/script verifier available. In the version after
 that, I expect this will be extended to further utxo set
 management, but no API has been worked out for that yet. There are
 also plans to add a library for transaction signing.
 
 However there is no goal to expose *everything* as a library. 
 Certainly not wallet- or user interface related functionality. 
 Specialized utility libraries would fill this purpose better. See
 for example https://github.com/bitcoin/libbase58 for base58
 processing.
 
 Wladimir
 
 --

 
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
 

- -- 
http://abis.io ~
a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJUd4SAAAoJEGxwq/inSG8Che8H/3PMt0NQSrVSqnC6WC9scXdD
aqGnsdZkhnLRs0szJSTjiQm+xCk6aUcEsKCGu298Xhkv38S4DSfWa+OhFZGPKmOZ
wlfnXAz3SprQ8xzy/NVqavtFRk+pGDRxgBIzzgBfbz3BdPKxMywi9BNnaK0YA6UA
08giKmtqblHTKmKuguK23YIYjAAk3Csg0Vg4BgN2MgeEXl9PJI6vh4+jNckXWtAT
/gKjPXG/Q+f9wl5pxSY/+ZfmRUtjHye3f8hHjpSEmxjpB9QzeeDg63DzAhOH0ip5
vXaIePZED//SmN3eH+S22vAx/a83URkr5B2+8Cffx/oO5laYRthoMHLi/2+XkO4=
=UWhs
-END PGP SIGNATURE-

--
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-11-27 Thread Gregory Maxwell
On Thu, Nov 27, 2014 at 5:44 PM, Mistr Bigs mister...@gmail.com wrote:
 I might be mistaken, but it seems to me this paper discusses unintended ways
 of obtaining the IP addresses of clients involved in transactions on the
 core Bitcoin network.

You're mistaken. :)

If a node is used exclusively via tor it effectively doesn't have a IP address.

(short of bugs of a class that aren't discussed here)

The paper is about fingerprinting approaches that probabilistically
connect transactions to hosts that you can already identify their IPs.

--
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


[Bitcoin-development] BIP 65 and OP_CHECKLOCKTIMEVERIFY inquiry...

2014-11-27 Thread Richard Moore
Heya,

I was wondering about BIP 65 regarding the OP_CHECKLOCKTIMEVERIFY, and thought 
it might make more sense to instead have a OP_CHECKLOCKTIME which would simply 
push an OP_TRUE or OP_FALSE onto the stack?

That way someone could include multiple OP_CHECKLOCKTIME conditions in a single 
script. It is trivial to always emulate OP_CHECKLOCKTIMEVERIFY by using a 
OP_CHECKLOCKTIME OP_VERIFY sequence.


As a second question, would it possibly make more sense to, rather than relying 
on the nLockTime in a transaction, allow an opcode that would use similar 
semantics, but against an item in the stack? Then you could essentially include 
multiple nLockTimes in a single script and make arbitrarily interesting 
(complicated?) scripts based on block height and/or block timestamp.

The OP_CHECKLOCKTIMEVERIFY can still be easily implemented, by using

nLockTimeThatWouldBeInTx OP_CHECKLOCKTIME OP_VERIFY


Just something that came to mind while reading about OP_CHECKLOCKTIMEVERIFY.

Thanks,

RicMoo

.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸(((º

Richard Moore ~ Founder
Genetic Mistakes Software inc.
phone: (778) 882-6125
email: ric...@geneticmistakes.com mailto:ric...@geneticmistakes.com
www: http://GeneticMistakes.com http://geneticmistakes.com/
--
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] BIP 65 and OP_CHECKLOCKTIMEVERIFY inquiry...

2014-11-27 Thread Gregory Maxwell
On Thu, Nov 27, 2014 at 10:56 PM, Richard Moore m...@ricmoo.com wrote:
 Heya,

 I was wondering about BIP 65 regarding the OP_CHECKLOCKTIMEVERIFY, and
 thought it might make more sense to instead have a OP_CHECKLOCKTIME which
 would simply push an OP_TRUE or OP_FALSE onto the stack?

Updating the stack is not soft-fork compatible and any use would
immediately fork the network.

A invertible test is also not soft-fork compatible e.g. someone writes
a script that does {new thing) OP_NOT,  in other words the test
must fail, then the network would fork because older nodes would see
it as passing (which was the required criteria for non-forking the
network in the non-inverted caes).

You can happily get non-nullable true/false behaviour without these
risks by having the VERIFY test inside a branch and having the signer
provide its falseness as an input to the branch. This is explained in
the BIP.

E.g. OP_IF limit OP_CHECKLOCKTIMEVERIFY OP_ELSE what you'd do if it
doesn't pass OP_END

A useful an powerful mental model is that SCRIPT is not running a
program, but instead the signer is proving to the network that they
know inputs that make the program return true.

(In practise we verify this by actually doing some execution, though
this isn't technically necessary it's the simplest thing to implement
although it is inefficient... but even in this simple model keeping in
mind that we're VERIFYING not executing in the network opens our eyes
to transformations like the IF bracketing of a VERIFY opcode.)

 That way someone could include multiple OP_CHECKLOCKTIME conditions in a
 single script.

They can do this, with the above approach.

 As a second question, would it possibly make more sense to, rather than
 relying on the nLockTime in a transaction, allow an opcode that would use
 similar semantics, but against an item in the stack? Then you could
 essentially include multiple nLockTimes in a single script and make
 arbitrarily interesting (complicated?) scripts based on block height and/or
 block timestamp.

 The OP_CHECKLOCKTIMEVERIFY can still be easily implemented, by using

 nLockTimeThatWouldBeInTx OP_CHECKLOCKTIME OP_VERIFY

Then the scripts validity isn't a pure function of the the
transaction, and once valid transactions could become invalid while in
the mempool. This breaks existing invariants and would make the coins
potentially less fungible because they wouldn't be reorg safe. That
locktime validity is basically monotonic is a useful intentional
property. :)


The things you're suggesting were all carefully designed out of the
proposal, perhaps the BIP text needs some more clarification to make
this more clear.

--
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-11-27 Thread Mistr Bigs
That's what I was trying to say... The researchers are deanonymizing
transactions from non-Tor connected hosts. So why are we talking about Tor
limitations in response to this? Shouldn't we be discussing how to address
the issues in Bitcoin proper?

M

On 11/27/2014 9:30 PM, Gregory Maxwell wrote:

On Thu, Nov 27, 2014 at 5:44 PM, mister...@gmail.com wrote:

I might be mistaken, but it seems to me this paper discusses unintended ways
of obtaining the IP addresses of clients involved in transactions on the
core Bitcoin network.

You're mistaken. :)

If a node is used exclusively via tor it effectively doesn't have a IP address.

(short of bugs of a class that aren't discussed here)

The paper is about fingerprinting approaches that probabilistically
connect transactions to hosts that you can already identify their IPs.
--
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] BIP 65 and OP_CHECKLOCKTIMEVERIFY inquiry...

2014-11-27 Thread Peter Todd
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 27 November 2014 18:46:23 GMT-05:00, Gregory Maxwell gmaxw...@gmail.com 
wrote:

snip 100% accurate commentary from gmaxwell

The things you're suggesting were all carefully designed out of the
proposal, perhaps the BIP text needs some more clarification to make
this more clear.

It does; it is still a draft. That said I think writing up some actual working 
examples, in code, of CHECKLOCKTIMEVERIFY using protocols is a bigger priority. 
Micropayment channels comes to mind, as well as a greenaddress-style wallet.

When I get a chance I'm going to rebase the initial implementation and add to 
it a command-line-flag to verify CHECKLOCKTIMEVERIFY as an IsStandard() rule 
for testing purposes.
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJUd+luMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhWmcB/0UK030Q6TSpi95x0Gh
hGYaSAInUWpbZzZtP+1AFrGDGRdGo0glFFf8xggI+U5kuc0woPYrn/VEGcprPhvs
KQFZrirXVr7Q09TVlHiPDen5v3Y7xwL5kQDUrBPP71Pe3R2o6IbfdwxsZ8+yYso8
hY6WQmImQpKJd4gEd76w1QrF8Btl1Jz/PGh4EE3GSPGlflvBwA6igSiRoD/czb1x
63y4AsPEil2hrmIjTZHqwnl40BqnmZ8qpNLWeIEjE++pbkxLTjvUcPy03/wtTWZA
5dCGeY5WavgZsPazhSdaTtM5/7wPSQQ0PDXNHdHgmewkvbyBpy78orV/3bEG+xFz
2SWi
=4OmI
-END PGP SIGNATURE-


--
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-11-27 Thread Gregory Maxwell
On Fri, Nov 28, 2014 at 12:45 AM, Mistr Bigs mister...@gmail.com wrote:
 That's what I was trying to say... The researchers are deanonymizing
 transactions from non-Tor connected hosts. So why are we talking about Tor
 limitations in response to this? Shouldn't we be discussing how to address
 the issues in Bitcoin proper?

Because if the user does not use tor or an analogous infrastructure
(e.g. something else reimplementing tor's functionality) the user can
be deanonymized in many different ways.

At the end of the day, if I'm listening widely to the network, and
your host is regularly the first to hand me your transactions then I
can draw reasonably reliable conclusions... and this is true even if
there is a complete absence of identifiable characteristics otherwise.

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).

--
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