Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)
You mean scam you with a zero-conf transaction that hasn't actually been broadcast? Yeah. Or just scam you at all. It's hard to imagine an organisation as a big as a mobile carrier engaging in financial scamming (roaming fees excepted). I've said this before, but I think it's worth repeating. The double-spend protection the block chain gives you has a sweet spot where it's really, really valuable (essential even) and then there are lots of kinds of transactions on either side of that sweet spot that don't really benefit from it. Obvious/trivial case where you don't need a block chain - Facebook buys Instagram for a gajillion coins. The legal system is plenty good enough to ensure the payments are honoured. Another example, when my employer pays me my salary. They aren't going to double spend this except through some horrible accident that we can get sorted out some other way. Another case, very small payments. This is Satoshi's bag of crisps example. If the cost/complexity of double spending is higher than what the payment is worth, again, you don't really need the block chain. That's why it's worth optimising unconfirmed transactions to be harder to double spend, it optimises (pushes up) that lower bar. Place where you really want the chain - largeish sums of money are moving around, but not large enough to justify expensive cross-jurisdictional legal action, or where the cost of identity verification and all the associated paperwork is just too high. I guess most online transactions fall into this bucket today. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] minor bitcoin-qt gripes moving BTC off specific key
sweep private key is the missing functionality. I agree, it would be nice to have. On Tue, May 7, 2013 at 8:16 AM, Adam Back a...@cypherspace.org wrote: Hi Three minor security/other issues: 1. please a way to unlock the wallet without displaying wallet password in console screen (console unlock wallet, to import priv key); or 2. a button to import a private key (and option to transfer it to another key - if you are not the sole controller the private key) 3. a UX way to transfer BTC off a specific adress (eg choose from address), rather than having to spend the entire wallet onto a new address, just to get BTC off a specific address. Doing it that way has problems: creates more network traffic/bigger packets, higher fees (if any transactions are young/low confirmation), and generally damages privacy as all your funds end up linked. -- -- Gavin Andresen -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] minor bitcoin-qt gripes moving BTC off specific key
On Tue, May 07, 2013 at 02:16:41PM +0200, Adam Back wrote: Hi Three minor security/other issues: 1. please a way to unlock the wallet without displaying wallet password in console screen (console unlock wallet, to import priv key); or I think the general solution here is providing a feature-reach Python RPC client, which can do things like remember passwords, command history/tab completion, perhaps even batch lookups of compound commands (getblock $(getblockhash X, for example, ...). The naive RPC client built into bitcoind is not a good fit for many features, as they can much more efficiently be developed outside of the core binary, 2. a button to import a private key (and option to transfer it to another key - if you are not the sole controller the private key) I'm quite opposed to any per-key fiddling in the GUI. This will inevitably lead to (even more) people misunderstanding how wallets work and shooting themself in the foot. I don't mind an expert mode (coin control) that enables such features, but in general, we should for entire-wallet export and import rather than individual keys. Import sweep an address is something else, that sounds safe to. 3. a UX way to transfer BTC off a specific adress (eg choose from address), rather than having to spend the entire wallet onto a new address, just to get BTC off a specific address. Doing it that way has problems: creates more network traffic/bigger packets, higher fees (if any transactions are young/low confirmation), and generally damages privacy as all your funds end up linked. This belongs in coin control, IMHO. -- Pieter -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] minor bitcoin-qt gripes moving BTC off specific key
At ZKS other than freedom network (ToR precursor) we had psueudonyms associated with cookie managers. The idea was you create pseudonyms for different purposes to segregate your online linkability. medical casual browsing social media private work true name Seems to me that people are always going to make mistakes with individual keys, even if the feature were there and accidentally link all their coin sources together. I presume people saw the analysis of the slush related 25k BTC theft, even seemingly the thief made possible slips while trying presumably not to: http://anonymity-in-bitcoin.blogspot.com/2011/07/bitcoin-is-not-anonymous.html Does the client have any privacy algorithm (to minimise coin source cross linking) to reach a given payment? eg consider say I use social media, with a screen name; I collect reddit tips etc; I pay them out to others, or use them to buy virtual goods associated with the same purpose. It would be rather useful to help people achieve that, there is already the ability to create addresses, label them. But I think just for the GUI to allow you to control which address the payment is from would be enough, it doesnt seem like such a complicated concept. And if people dont care, they only need create one address. Technically ZKS wasnt anonymous networking like ToR but pseudonymous networking. Multiple wallets for different unlinked purposes would be somewhat analogous to ZKS freedom pseudonymous networking cookie-jar. Because of the pseudonymity in ZKS misbehavers could be blocked by exit nodes based on pseudonym. Of course they can always create a new pseudonym but then they lose their accumulated reputation. You can even make people pay for pseudonyms, as I recall users got 5 free pseudonyms but had to pay for more. (Though I have to admit the concensus after some years at ZKS was most end users didnt understand what a pseudonym was! They just wanted to be private and have the computer magically solve it for them.) If you want to simplify maybe you could consider normal (linked to AML trading accounts, orders for physically delivered goods etc), and private analogus to the private browsing mode in various browsers. Maybe beyond 2 is an advanced feature but still available. Adam On Tue, May 07, 2013 at 03:19:50PM +0200, Pieter Wuille wrote: On Tue, May 07, 2013 at 02:16:41PM +0200, Adam Back wrote: Hi Three minor security/other issues: 1. please a way to unlock the wallet without displaying wallet password in console screen (console unlock wallet, to import priv key); or I think the general solution here is providing a feature-reach Python RPC client, which can do things like remember passwords, command history/tab completion, perhaps even batch lookups of compound commands (getblock $(getblockhash X, for example, ...). The naive RPC client built into bitcoind is not a good fit for many features, as they can much more efficiently be developed outside of the core binary, 2. a button to import a private key (and option to transfer it to another key - if you are not the sole controller the private key) I'm quite opposed to any per-key fiddling in the GUI. This will inevitably lead to (even more) people misunderstanding how wallets work and shooting themself in the foot. I don't mind an expert mode (coin control) that enables such features, but in general, we should for entire-wallet export and import rather than individual keys. Import sweep an address is something else, that sounds safe to. 3. a UX way to transfer BTC off a specific adress (eg choose from address), rather than having to spend the entire wallet onto a new address, just to get BTC off a specific address. Doing it that way has problems: creates more network traffic/bigger packets, higher fees (if any transactions are young/low confirmation), and generally damages privacy as all your funds end up linked. This belongs in coin control, IMHO. -- Pieter -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] minor bitcoin-qt gripes moving BTC off specific key
BTW, Adam, I suspect you might be using the console in the GUI, and that might be under Windows for all I know, but I usually do it this way on the command line under Linux: echo -n Password: ;bitcoind walletpassphrase `stty -echo;read p;echo $p;stty echo` 60; echo This uses the JSON API to unlock the wallet (for 60 seconds; which is the 60 at the end), and should work for either the GUI (if you start it with the -server flag) or the headless bitcoind. It keeps the password that you type off the console, and also keeps it out of the history file. The only issue with it is that it will show up in the process tree as an argument of the command for the period of time that the JSON API is being prepared and sent, which should be fairly short. This might be a concern if you are on a multi-user system (you probably shouldn't be doing this anyway), or worry that spyware might be monitoring for passwords (though if you are worried about spyware, you should already be concerned about keyloggers, so...) I doubt this will work (without significant modifications) on Windows without Cygwin, though. -Craig On Tue, May 07, 2013 at 02:16:41PM +0200, Adam Back wrote: Hi Three minor security/other issues: 1. please a way to unlock the wallet without displaying wallet password in console screen (console unlock wallet, to import priv key); or -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] limits of network hacking/netsplits (was: Discovery/addr packets)
I really beg to differ on this one. If you're an Ubuntu user who is behind only one distro (quantal) you're stuck on version 0.6.2 with no updates since 2012 (yes, that means on May 15th you'll be lost). For those still on Debian Squeeze (ie barely out of date), you get 0.3.24! Yes, 0.3.24 including every issue we've fixed since (https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures) and bitcoin is not available in wheezy. Those are just the two I bothered to look up, but, additionally, nearly every distro I know of links bitcoin against libdb5.1 (latest Ubuntu, Arch, etc) which means wallets run once with those packages will never be usable an official Bitcoin build ever again. I can't necessarily fault them for this since 4.8 is quite old, but its certainly not doing mostly a pretty good job Matt On Mon, 2013-05-06 at 23:48 -0500, Petr Praus wrote: I think it's worth noting that quite a large portion of Linux users probably get the mainline Bitcoin client from the packages. I think Bitcoin package maintainers are doing mostly a pretty good job :) -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
