Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)

2013-05-07 Thread Mike Hearn
 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


[Bitcoin-development] WebCryto standard to support secp256r1 but not secp256k1

2013-05-07 Thread Melvin Carvalho
Looking at the proposed native crypto browser support (should arrive in the
next year)

http://www.w3.org/TR/WebCryptoAPI/#EcKeyGenParams-dictionary

We see:

enum NamedCurve {
  // NIST recommended curve P-256, also known as secp256r1.
  P-256,
  // NIST recommended curve P-384, also known as secp384r1.
  P-384,
  // NIST recommended curve P-521, also known as secp521r1.
  P-521
};

I wonder if we might be able to get bitcoin's curve in there

For more background on Koblitz curve used by bitcoin see:

https://bitcointalk.org/?topic=2699.0
--
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

2013-05-07 Thread Gavin Andresen
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

2013-05-07 Thread Pieter Wuille
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

2013-05-07 Thread Adam Back
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

2013-05-07 Thread Craig B Agricola
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)

2013-05-07 Thread Matt Corallo
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