Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper
[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
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
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
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
-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
[Bitcoin-development] BIP 65 and OP_CHECKLOCKTIMEVERIFY inquiry...
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...
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
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...
-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
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