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

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

[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

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

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

[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

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

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:

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

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