Re: [Bitcoin-development] Stealth Addresses

2014-01-17 Thread Natanael
So far I've only liked the original name Stealth address and the
suggestion routing address.

Should we put this up for some kind of informal vote with comments allowed?
Like a Google docs form?

- Sent from my phone
Den 17 jan 2014 10:18 skrev Mike Hearn m...@plan99.net:

 I must say, this shed is mighty fine looking. It'd be a great place to
 store our bikes. But, what colour should we paint it?

 How about we split the difference and go with privacy address? As Peter
 notes, that's what people actually like and want. The problem with stealth
 is it's got strong connotations with American military hardware and perhaps
 thieves sneaking around in the night:

https://www.google.com/search?tbm=ischq=stealth

 But everyone loves privacy.


 On Fri, Jan 17, 2014 at 8:49 AM, Drak d...@zikula.org wrote:

 Peter I agree with you about  reusable addresses, but aren't we also
 trying to get away from the word address entirely?  How about calling it
 a payment key or reusable payment key instead? using stealth is just
 asking for bad press imo.


 On 16 January 2014 21:28, Peter Todd p...@petertodd.org wrote:

 On Wed, Jan 15, 2014 at 04:05:27PM -0800, Jeremy Spilman wrote:
  Might I propose reusable address.
 
  I think that describes it best to any non-programmer, and even more
  so encourages wallets to present options as 'one time use' vs
  'reusable'.
 
  It definitely packs a marketing punch which could help drive
  adoption. The feature is only useful if/when broadly adopted.

 I'm very against the name reusable addresses and strongly belive we
 should stick with the name stealth addresses.

 You gotta look at it from the perspective of a user; lets take standard
 pay-to-pubkey-hash addresses: I can tell my wallet to pay one as many
 times as I want and everything works just great. I also can enter the
 address on blockchain.info's search box, and every transaction related
 to the address, and the balance of it, pops up immediately.

 What is that telling me? A: Addresses starting with 1 are reusable. B:
 Transactions associated with them appear to be public knowledge.

 Now I upgrade my wallet software and it says I now have a reusable
 address. My reaction is Huh? Normal addresses are reusable, what's
 special about this weird reusable address thing that my buddy Bob's
 wallet software couldn't pay. I might even try to enter in a reusable
 address in blockchain.info, which won't work, and I'll just figure
 must be some new unsupported thing and move on with my life.

 On the other hand, suppose my wallet says I now have stealth address
 support. I'm going to think Huh, stealth? I guess that means privacy
 right? I like privacy. If I try searching for a stealth address on
 blockchain.info, when it doesn't work I might think twig on Oh right!
 It said stealth addresses are private, so maybe the transactions are
 hidden? I might also think Maybe this is like stealth/incognito mode
 in my browser? So like, there's no history being kept for others to
 see? Regardless, I'm going to be thinking well I hear scary stuff
 about Bitcoin privacy, and this stealth thing sounds like it's gonna
 help, so I should learn more about that

 Finally keep in mind that stealth addresses have had a tonne of very
 fast, and very wide reaching PR. The name is in the public conciousness
 already, and trying to change it now just because of vague bad
 associations is going to throw away the momentum of that good PR and
 slow down adoption. Last night I was at the Toronto Bitcoin Meetup and I
 based on conversations there with people there, technical and
 non-technical, almost everyone had heard about them and almost everyone
 seemed to understand the basic idea of why they were a good thing. That
 just wouldn't have happened with a name that tried to hide what stealth
 addresses were for, and by changing the name now we risk people not
 making the connection when wallet software gets upgraded to support
 them.

 --
 'peter'[:-1]@petertodd.org
 0001b0e0ae7ef97681ad77188030b6c791aef304947e6f524740


 --
 CenturyLink Cloud: The Leader in Enterprise Cloud Services.
 Learn Why More Businesses Are Choosing CenturyLink Cloud For
 Critical Workloads, Development Environments  Everything In Between.
 Get a Quote or Start a Free Trial Today.

 http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




 --
 CenturyLink Cloud: The Leader in Enterprise Cloud Services.
 Learn Why More Businesses Are Choosing CenturyLink Cloud For
 Critical Workloads, Development Environments  Everything In Between.
 Get a Quote or Start a Free Trial Today.

 

Re: [Bitcoin-development] bitcoinj 0.11 released, with p2sh, bip39 and payment protocol support

2014-02-04 Thread Natanael
Because it's trivial to create collisions! You can choose exactly what
output you want. That's why XOR is a very bad digest scheme.

- Sent from my phone
Den 4 feb 2014 14:20 skrev Peter Todd p...@petertodd.org:

 On Tue, Feb 04, 2014 at 02:13:12PM +0100, Mike Hearn wrote:
  Hah, good point. If nobody completes the homework, I'll post a fixed
  version tomorrow :)

 Heh, here's another 25mBTC while we're at it:


 https://github.com/opentimestamps/opentimestamps-client/commit/288f3c17626974de7eaef4f1c9b5cd93eecf40f6

 Why is that a bad idea?

 Bonus question: What was I smoking? (hint: where do I live?)

  On Tue, Feb 4, 2014 at 2:03 PM, Peter Todd p...@petertodd.org wrote:
 
   On Tue, Feb 04, 2014 at 01:01:12PM +0100, Mike Hearn wrote:
Hello,
   
I'm pleased to announce the release of bitcoinj 0.11, a library for
   writing Bitcoin applications that run on the JVM. BitcoinJ is widely
 used
   across the Bitcoin community; some users include Bitcoin Wallet for
   Android, MultiBit, Hive, blockchain.info, the biteasy.com block
 explorer
   (written in Lisp!), Circle, Neo/Bee (Cypriot payment network),
 bitpos.me,
   Bitcoin Touch, BlueMatt's relay network and DNS crawler, academic
 advanced
   contracts research and more.
   
The release-0.11 git tag is signed by Andreas Schildbach's GPG key.
 The
   commit hash is 410d4547a7dd. This paragraph is signed by the same
 Bitcoin
   key as with previous releases (check their release announcements to
   establish continuity). Additionally, this email is signed using DKIM
 and
   for the first time, a key that was ID verified by the Swiss government.
   
Key: 16vSNFP5Acsa6RBbjEA7QYCCRDRGXRFH4m
Signature for last paragraph:
  
 H3DvWBqFHPxKW/cdYUdZ6OHjbq6ZtC5PHK4ebpeiE+FqTHyRLJ58BItbC0R2vo77h+DthpQigdEZ0V8ivSM7VIg=
  
   The above makes for a great homework problem for budding
 cryptographers:
   Why did the three forms of signature, DKIM, long-lived bitcoin address,
   and Official Swiss Government Identity fail to let you actually verify
   you have the right code? (but make for great security theater)
  
   Bonus question: Who has the smallest work-factor for such an attack?
  
   Two rewards of 25mBTC for correct responses to each question from a
   crypto newbie.
  
Thanks to Mike Belshe, the wallet can now send to P2SH addresses.
  
   Thanks
  
Generated signatures now use canonical S values. This will aid a
 future
   hard-forking rule change which bans malleable signatures.
  
   Soft-forking rule change.
  
   --
   'peter'[:-1]@petertodd.org
   75829f6169c79d7d5aaa20bfa8da6e9edb2393c4f8662ba0
  

 --
 'peter'[:-1]@petertodd.org
 75829f6169c79d7d5aaa20bfa8da6e9edb2393c4f8662ba0


 --
 Managing the Performance of Cloud-Based Applications
 Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
 Read the Whitepaper.

 http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-19 Thread Natanael
Regarding chains of transactions intended to be published at once together,
wouldn't it be easier to add a only-mine-with-child flag?

That way the parent transactions aren't actually valid unless spent
together with the transaction that depends on it, and only the original
will have a child referencing it.

Then malleability is not an issue at all for transaction chains if you only
need to broadcast your full transaction chain once, and don't need to
extend it in two or more occasions, *after* broadcasting subchains to the
network, from the same set of pregenerated transactions.

If you need to broadcast pregenerated subchains separately, then you need
the last child in the chain to be non-malleable.

This would require all miners to start to respect it at once in order to
avoid forking the network.

- Sent from my phone
Den 19 feb 2014 22:13 skrev Pieter Wuille pieter.wui...@gmail.com:

 On Wed, Feb 19, 2014 at 9:28 PM, Michael Gronager grona...@mac.com
 wrote:
  I think that we could guarantee fewer incidents by making version 1
 transactions unmalleable and then optionally introduce a version 3 that
 supported the malleability feature. That way most existing problematic
 implementations would be fixed and no doors were closed for people
 experimenting with other stuff - tx v 3 would probably then be called
 experimental transactions.

 Just to be clear: this change is not directly intended to avoid
 incidents. It will take way too long to deploy this. Software should
 deal with malleability. This is a longer-term solution intended to
 provide non-malleability guarantees for clients that a) are upgraded
 to use them  b) willing to restrict their functionality. As there are
 several intended use cases for malleable transactions (the sighash
 flags pretty directly are a way to signify what malleabilities are
 *wanted*), this is not about outlawing malleability.

 While we could right now make all these rules non-standard, and
 schedule a soft fork in a year or so to make them illegal, it would
 mean removing potential functionality that can only be re-enabled
 through a hard fork. This is significantly harder, so we should think
 about it very well in advance.

 About new transaction and block versions: this allows implementing and
 automatically scheduling a softfork without waiting for wallets to
 upgrade. The non-DER signature change was discussed for over two
 years, and implemented almost a year ago, and we still notice wallets
 that don't support it. We can't expect every wallet to be instantly
 modified (what about hardware wallets like the Trezor, for example?
 they may not just be able to be upgraded). Nor is it necessary: if
 your software only spends confirmed change, and tracks all debits
 correctly, there is no need.

 --
 Pieter


 --
 Managing the Performance of Cloud-Based Applications
 Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
 Read the Whitepaper.

 http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-19 Thread Natanael
You could pregenerate entire trees of alternative outcomes where you pick
one branch / chain to broadcast based on the real world events as they
happen.

But I see another problem regarding use of oracles, if you have a P2SH
address with 2-of-3 signatures or similar in the chain, amd some
transactions following it, then the oracle needs to pregenerate both
transactions for both outcomes in advance. But the oracle probably don't
want to actually share it in advance to any third party before the event
happened.

This can be solved if the oracle only shares the transaction hash in
advance and then hands out a Zero-knowledge proof of that transaction with
the given hash is following the agreed upon rules, so you can trust the
transaction chain anyway and still being able to pregenerate a full tree of
transactions.

And then the oracle will release one of the possible transactions after the
event in question has happened, so you can broadcast the chain of choice.

This unfortunately breaks down if the number of possible outcomes becomes
too many as you would need to both generate and store a tree of possible
outcomes that is massive.

- Sent from my phone
Den 20 feb 2014 02:29 skrev Allen Piscitello allen.piscite...@gmail.com:

 This is somewhat problematic in my use case since some parts need to be in
 the chain earlier than others and have the same ID as expected.

 https://bitcointalk.org/index.php?topic=260898.10

 I haven't gone back to see if there are any ways around it, but the main
 problem here is I need the Contract TX to be in the chain much earlier than
 redeeming, but I need the refund transaction to be in the chain much
 earlier.  Perhaps there are some tricks to pull off to get it to work, but
 I haven't been working on this for a while so I'm a bit rusty in that area.

 This might be helpful enough to help a lot of use cases, but shouldn't be
 final.

 -Allen

 On Wed, Feb 19, 2014 at 6:22 PM, Natanael natanae...@gmail.com wrote:

 Regarding chains of transactions intended to be published at once
 together, wouldn't it be easier to add a only-mine-with-child flag?

 That way the parent transactions aren't actually valid unless spent
 together with the transaction that depends on it, and only the original
 will have a child referencing it.

 Then malleability is not an issue at all for transaction chains if you
 only need to broadcast your full transaction chain once, and don't need to
 extend it in two or more occasions, *after* broadcasting subchains to the
 network, from the same set of pregenerated transactions.

 If you need to broadcast pregenerated subchains separately, then you need
 the last child in the chain to be non-malleable.

 This would require all miners to start to respect it at once in order to
 avoid forking the network.

 - Sent from my phone
 Den 19 feb 2014 22:13 skrev Pieter Wuille pieter.wui...@gmail.com:

 On Wed, Feb 19, 2014 at 9:28 PM, Michael Gronager grona...@mac.com
 wrote:
  I think that we could guarantee fewer incidents by making version 1
 transactions unmalleable and then optionally introduce a version 3 that
 supported the malleability feature. That way most existing problematic
 implementations would be fixed and no doors were closed for people
 experimenting with other stuff - tx v 3 would probably then be called
 experimental transactions.

 Just to be clear: this change is not directly intended to avoid
 incidents. It will take way too long to deploy this. Software should
 deal with malleability. This is a longer-term solution intended to
 provide non-malleability guarantees for clients that a) are upgraded
 to use them  b) willing to restrict their functionality. As there are
 several intended use cases for malleable transactions (the sighash
 flags pretty directly are a way to signify what malleabilities are
 *wanted*), this is not about outlawing malleability.

 While we could right now make all these rules non-standard, and
 schedule a soft fork in a year or so to make them illegal, it would
 mean removing potential functionality that can only be re-enabled
 through a hard fork. This is significantly harder, so we should think
 about it very well in advance.

 About new transaction and block versions: this allows implementing and
 automatically scheduling a softfork without waiting for wallets to
 upgrade. The non-DER signature change was discussed for over two
 years, and implemented almost a year ago, and we still notice wallets
 that don't support it. We can't expect every wallet to be instantly
 modified (what about hardware wallets like the Trezor, for example?
 they may not just be able to be upgraded). Nor is it necessary: if
 your software only spends confirmed change, and tracks all debits
 correctly, there is no need.

 --
 Pieter


 --
 Managing the Performance of Cloud-Based Applications
 Take advantage of what the Cloud has to offer - Avoid Common Pitfalls

Re: [Bitcoin-development] New side channel attack that can recover Bitcoin keys

2014-03-06 Thread Natanael
You've heard of TRESOR?

No, not Trezor.

https://en.wikipedia.org/wiki/TRESOR

Signing on the CPU, without touching RAM.

- Sent from my phone
Den 6 mar 2014 09:41 skrev Mike Hearn m...@plan99.net:

 I'm wondering about whether (don't laugh) moving signing into the kernel
 and then using the MTRRs to disable caching entirely for a small scratch
 region of memory would also work. You could then disable pre-emption and
 prevent anything on the same core from interrupting or timing the signing
 operation.

 However I suspect just making a hardened secp256k1 signer implementation
 in userspace would be of similar difficulty, in which case it  would
 naturally be preferable.


 On Wed, Mar 5, 2014 at 11:25 PM, Gregory Maxwell gmaxw...@gmail.comwrote:

 On Wed, Mar 5, 2014 at 2:14 PM, Eric Lombrozo elombr...@gmail.com
 wrote:
  Everything you say is true.
 
  However, branchless does reduce the attack surface considerably - if
 nothing else, it significantly ups the difficulty of an attack for a
 relatively low cost in program complexity, and that might still make it
 worth doing.

 Absolutely. I believe these things are worth doing.

 My comment on it being insufficient was only that my signer is
 branchless doesn't make other defense measures (avoiding reuse,
 multsig with multiple devices, not sharing hardware, etc.)
 unimportant.

  As for uniform memory access, if we avoided any kind of heap
 allocation, wouldn't we avoid such issues?

 No. At a minimum to hide a memory timing side-channel you must perform
 no data dependent loads (e.g. no operation where an offset into memory
 is calculated). A strategy for this is to always load the same values,
 but then mask out the ones you didn't intend to read... even that I'd
 worry about on sufficiently advanced hardware, since I would very much
 not be surprised if the processor was able to determine that the load
 had no effect and eliminate it! :) )

 Maybe in practice if your data dependencies end up only picking around
 in the same cache-line it doesn't actually matter... but it's hard to
 be sure, and unclear when a future optimization in the rest of the
 system might leave it exposed again.

 (In particular, you can't generally write timing sign-channel immune
 code in C (or other high level language) because the compiler is
 freely permitted to optimize things in a way that break the property.
 ... It may be _unlikely_ for it to do this, but its permitted— and
 will actually do so in some cases—, so you cannot be completely sure
 unless you check and freeze the toolchain)

  Anyhow, without having gone into the full details of this particular
 attack, it seems the main attack point is differences in how squaring and
 multiplication (in the case of field exponentiation) or doubling and point
 addition (in the case of ECDSA) are performed. I believe using a branchless
 implementation where each phase of the operation executes the exact same
 code and accesses the exact same stack frames would not be vulnerable to
 FLUSH+RELOAD.

 I wouldn't be surprised.


 --
 Subversion Kills Productivity. Get off Subversion  Make the Move to
 Perforce.
 With Perforce, you get hassle-free workflows. Merge that actually works.
 Faster operations. Version large binaries.  Built-in WAN optimization and
 the
 freedom to use Git, Perforce or both. Make the move to Perforce.

 http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




 --
 Subversion Kills Productivity. Get off Subversion  Make the Move to
 Perforce.
 With Perforce, you get hassle-free workflows. Merge that actually works.
 Faster operations. Version large binaries.  Built-in WAN optimization and
 the
 freedom to use Git, Perforce or both. Make the move to Perforce.

 http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Subversion Kills Productivity. Get off Subversion  Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net

Re: [Bitcoin-development] moving the default display to mbtc

2014-03-14 Thread Natanael
Regarding (ISO standards) currency symbols, XBT is already used as
equivalent to 1 Bitcoin in numerous places, and XBC is taken and BT*
belongs to Bhutan (and X** is already the default for non-national currency
common items of trade), so IMHO we should define something like XUB as
microbitcoins so we can have a symbol that doesn't require changing any
existing systems and that can be standardized globally. Then those with
accounting software that needs to deal with something that has two decimals
maximum without losing precision can use that while following well defined
standards. And those who don't like large numbers can still chose to show
mBTC.

- Sent from my phone
Den 14 mar 2014 18:18 skrev vv01f vv...@riseup.net:

 I think
 * if we change to mBTC because your state currencys price for bitcoin
 make this a valid option we will change again in future
 * users do not like changes
 * we should keep a good standard

 A good standard should be
 * built on standards (e.g. SI)
 * backed by best practice: never force the user to take an option he
 cannot change
 * do not make changes without users permission
 * take care of users at fault when entering 5.967 ot should be pointed
 out before sending that e.g.
 the sw understood 5967.000 000 00 BTC
 instead of 5.967 000 00 BTC
 because the user failed to use the correct delimiter.

 For now a good standard is
 * simply bitcoin as BTC with eight decimal places
 or could be
 * uBTC as SI prefix, probably using XBT as a symbol for compatibility
 with other software
 * satoshis (w. SI prefixes if numbers are to big) for regions where
 decimal places in prices are uncommon

 So I'd prefer:
 Make the choice transparent to users and set a standard that the user
 alway should be empowered to use all available decimal places.
 And there should be a set of official test-cases for wallet software and
 the desired behavior.


 --
 Learn Graph Databases - Download FREE O'Reilly Book
 Graph Databases is the definitive new guide to graph databases and their
 applications. Written by three acclaimed leaders in the field,
 this first edition is now available. Download your free book today!
 http://p.sf.net/sfu/13534_NeoTech
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

2014-03-29 Thread Natanael
Den 29 mar 2014 19:15 skrev Matt Whitlock b...@mattwhitlock.name:

 On Saturday, 29 March 2014, at 2:08 pm, Alan Reiner wrote:
  Regardless of how  does it, I believe that obfuscating that
  information is bad news from a usability perspective.  Undoubtedly,
  users will make lots of backups of lots of wallets and think they
  remember the M-parameter but don't.  They will accidentally mix in some
  3-of-5 fragments with their 2-of-4 not realizing they are incompatible,
  or not able to distinguish them.   Or they'll distribute too many
  thinking the threshold is higher and end up insecure, or possibly not
  have enough fragments to restore their wallet thinking the M-value was
  lower than it actually was.
 
  I just don't see the value in adding such complexity for the benefit of
  obfuscating information an attacker might be able to figure out anyway
  (most backups will be 2-of-N or 3-of-N) and can't act on anyway (because
  he doesn't know where the other frags are and they are actually in
  safe-deposit boxes)

 Okay, you've convinced me. However, it looks like the consensus here is
that my BIP is unneeded, so I'm not sure it would be worth the effort for
me to improve it with your suggestions.

I think it should be made an option (with the default being that the
threshold is given and verification is applied. There could certainly be a
few cases where the threshold is set high, you maybe don't have access to a
great enough variety of hiding spots or secure enough hiding spots, and you
want deter an attempt to find all the shares (with the idea being that the
risk of detection would be too high, in particular when you use tamper
evident seals). But for the majority it would be better to find a few
different safeboxes to put the shares in and rely on physical security.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] secure assigned bitcoin address directory

2014-03-31 Thread Natanael
Does't BIP70 cover this already via Certificate Authorities?

On Mon, Mar 31, 2014 at 12:21 PM, vv01f vv...@riseup.net wrote:
 Some users on bitcointalk[0] would like to have their vanity addresses
 available for others easily to find and verify the ownership over a kind
 of WoT. Right now they sign their own addresses and quote them in the
 forums.
 As I pointed out there already the centralized storage in the forums is
 not secury anyhow and signed messages could be swapped easily with the
 next hack of the forums.

 Is that use case taken care of in any plans already?

 I thought about abusing pgp keyservers but that would suit for single
 vanity addresses only.
 It seems webfinger could be part of a solution where servers of a
 business can tell and proof you if a specific address is owned by them.

 [0] https://bitcointalk.org/index.php?topic=502538
 [1] https://bitcointalk.org/index.php?topic=505095


 --

 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] secure assigned bitcoin address directory

2014-03-31 Thread Natanael
This sounds like Namecoin. You can already register profiles with it,
including keypairs. onename.io is a web-based client you can use to
register on the Namecoin blockchain.

On Mon, Mar 31, 2014 at 1:14 PM, Chris D'Costa chris.dco...@meek.io wrote:
 Security of transmission of person-to-person pay-to addresses is one of the 
 use cases that we are addressing on our hardware wallet.

 I have yet to finish the paper but in a nutshell it uses a decentralised 
 ledger of, what we refer to as, device keys.

 These keys are not related in any way to the Bitcoin keys, (which is why I'm 
 hesitating about discussing it here) neither do they even attempt to identify 
 the human owner if the device. But they do have a specific use case and that 
 is to provide advanced knowledge of a publickey that can be used for 
 encrypting a message to an intended recipient, without the requirement for a 
 third-party CA, and more importantly without prior dialogue. We think it is 
 this that would allow you to communicate a pay-to address to someone without 
 seeing them in a secure way.

 As I understand it the BlockChain uses time bought through proof of work to 
 establish a version of the truth, we are using time in the reverse sense : 
 advanced knowledge of all pubkeys. Indeed all devices could easily check 
 their own record to identify problems on the ledger.

 There is of course more to this, but I like to refer to the distributed 
 ledger of device keys as the Web-of-trust re-imagined although that isn't 
 strictly true.

 Ok there you have it. The cat is out of the bag, feel free to give feedback, 
 I have to finish the paper, apologies if it is not a topic for this list.

 Regards

 Chris D'Costa


 On 31 Mar 2014, at 12:21, vv01f vv...@riseup.net wrote:

 Some users on bitcointalk[0] would like to have their vanity addresses
 available for others easily to find and verify the ownership over a kind
 of WoT. Right now they sign their own addresses and quote them in the
 forums.
 As I pointed out there already the centralized storage in the forums is
 not secury anyhow and signed messages could be swapped easily with the
 next hack of the forums.

 Is that use case taken care of in any plans already?

 I thought about abusing pgp keyservers but that would suit for single
 vanity addresses only.
 It seems webfinger could be part of a solution where servers of a
 business can tell and proof you if a specific address is owned by them.

 [0] https://bitcointalk.org/index.php?topic=502538
 [1] https://bitcointalk.org/index.php?topic=505095

 --
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

 --
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] bits: Unit of account

2014-04-22 Thread Natanael
I am in favor of xbit, my only concern is if average Joes will consider
that name stupid (like various attempts at cool branding with unusual
letters like Q, X, Z, etc). We should see if we can get support for it in
the community and if there would be any notable opposition against it or
not. If there's no significant opposition and most people are in favor, I'd
say go ahead.

- Sent from my phone
Den 21 apr 2014 11:38 skrev Tamas Blummer ta...@bitsofproof.com:

 Thomas V:

 Your proposal misses the points that:

 - this is about a unit with 1e-6 Bitcoins or 100 satoshis.
 - it is not about people who know Bitcoin and are techies, but about those
 who don’t and aren’t.

 The reasons for such a unit are more than shifting the comma some places
 for convinience,
 but to align Bitcoin with capabilities of existing financial software and
 customs of finance and average people,
 and ISO standard of currency abbreviations.

 bit and XBT seems to check the boxes.

 I would love to have some feedback on xbit as per my previous mail.

 Regards,

 Tamas Blummer
 http://bitsofproof.com



 --
 Start Your Social Network Today - Download eXo Platform
 Build your Enterprise Intranet with eXo Platform Software
 Java Based Open Source Intranet - Social, Extensible, Cloud Ready
 Get Started Now And Turn Your Intranet Into A Collaboration Platform
 http://p.sf.net/sfu/ExoPlatform
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Paper Currency

2014-05-18 Thread Natanael
Now you are talking about Trusted Platform Modules. Like smartcards,
actually. Devices that won't leak their keys but let the holder spend the
coins. It could even have it's own simple SPV wallet client to make it
easier to handle. And they'd use the attestation features provided by the
TPM to prove the software it's unmodified top the current holder.

But then you still have to trust the manufacturer of the device, and you
have to trust it has no exploitable side channels.

- Sent from my phone
Den 18 maj 2014 13:52 skrev Alex Kotenko alexy...@gmail.com:

 I had a long discussion recently with somebody who wants and has resources
 to do exactly this - paper currency representing bitcoins. Yet we've been
 thinking mostly about a centralized solution, where one party is producing
 and maintaining paper currency, with bitcoins tied to each note verifiable
 via blockchain.

 The points we've ended up is that it needs to be:
 - reloadable
 - NFC based
 So anybody can verify any notes instantly by just touching it with his
 phone, and so merchants could redeem the notes at the moment of accepting
 it, convert it into fully online bitcoins and avoid costs of maintaining
 paper money turnover. Probably merchant would sell back redeemed
 empty notes to the issuer for a price of the note issue, and issuer will
 recharge it and put back into circulation.

 One problem we couldn't figure out here though - how to protect the notes
 from unauthorized redeem. Like if someone else tries to reach your wallet
 with his own NFC - how can we distinguish between deliberate redeem by
 owner and fraudulent redeem by anybody else with custom built long
 range NFC antenna? Any ideas?


 Best regards,
 Alex Kotenko


 2014-05-17 17:40 GMT+01:00 Gregory Maxwell gmaxw...@gmail.com:

 On Sat, May 17, 2014 at 9:07 AM, Chris Pacia ctpa...@gmail.com wrote:
  I can't really just hand someone the note and walk away
  because they have to scan it to see if it is actually valid.

 Not just scan it, but they actually must successfully sweep it—
 otherwise they can be trivially double spent. This is especially bad
 since any prior bearer can perform such an attack. E.g. record the
 private key of everyone that passes through your hands and then
 doublespend race any redemption that happens 24 hours after you spend
 them. The wrong person would likely be blamed and even if you were
 blamed you could plausibly deny it (Must have been the guy that gave
 it to me!).

 Othercoin seems to have much better properties in the space of offline
 transactions: https://bitcointalk.org/index.php?topic=319146.0

 Separately, Cassius also ran into some regulatory issues selling
 physical bitcoin artifacts. Especially printing things that seem to be
 redeemable for a named USD value sounds especially problematic.

 Some random comments— The base58 encoding is fairly human unfriendly.
 It's fine for something being copy and pasted, but I've found typing
 or reading it works poorly due to mixed case.  I expect the A/B side
 to be difficult to educate users about. This side is private is more
 easily understood, you could just pick one of your sides and call it
 private.  I find it kind of odd that this design seems to have no
 facility for checking its txouts without recovering the private key,
 though considering no one should rely on such a measurement without
 sweeping perhaps thats for the best.

 (As far as the numbering goes, I think you should be calling these
 draft-felix-paper-currency  etc. As a matter of hygienic practice I
 will not assign a matching bip number for something that went public
 with a number outside of the assignment.)


 --
 Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
 Instantly run your Selenium tests across 300+ browser/OS combos.
 Get unparalleled scalability from the best Selenium testing platform
 available
 Simple to use. Nothing to install. Get started now for free.
 http://p.sf.net/sfu/SauceLabs
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




 --
 Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
 Instantly run your Selenium tests across 300+ browser/OS combos.
 Get unparalleled scalability from the best Selenium testing platform
 available
 Simple to use. Nothing to install. Get started now for free.
 http://p.sf.net/sfu/SauceLabs
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run 

Re: [Bitcoin-development] Paper Currency

2014-05-18 Thread Natanael
The problem with not involving any electronics is that somebody needs to
generate a recoverable private key that we have to trust haven't recovered
the private key.

The only plausible solution is multisignature P2SH addresses where you
trust several independent entities to not collude instead, where you
combine their paper notes into one piece. And then you still don't know if
all the private keys are recoverable to you (failed print?).

- Sent from my phone
Den 18 maj 2014 20:48 skrev Alex Kotenko alexy...@gmail.com:

 Erm, few things here.
 ​- I can't see really how to embed electronics capable to run an SPV
 cli​ent into printed paper. I know that passive NFC tags can be printed on
 paper, but not actual chips and/or power modules. So we are talking about a
 completely different things here.
 - even with paper notes printed proprietarily by some business the notes
 itself still can have routes for independent blockchain-based verification,
 and you won't need to trust anybody to test it. You will have to trust
 security of the notes itself, but this is same as when you trust the phone
 manufacturer when you're putting your bitcoin wallet on it.

 ​So really I see ​only issues of technical security in here, and this is
 the problem I'm seeking solutions for.


 Best regards,
 Alex Kotenko


 2014-05-18 14:50 GMT+01:00 Natanael natanae...@gmail.com:

 Now you are talking about Trusted Platform Modules. Like smartcards,
 actually. Devices that won't leak their keys but let the holder spend the
 coins. It could even have it's own simple SPV wallet client to make it
 easier to handle. And they'd use the attestation features provided by the
 TPM to prove the software it's unmodified top the current holder.

 But then you still have to trust the manufacturer of the device, and you
 have to trust it has no exploitable side channels.

 - Sent from my phone
 Den 18 maj 2014 13:52 skrev Alex Kotenko alexy...@gmail.com:
 ​


--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension

2014-06-18 Thread Natanael
Den 17 jun 2014 17:59 skrev Isidor Zeuner cryptocurrenc...@quidecco.de:

 quote:
  Mike Hearn, why don't we just have all nodes report attempted double
spends
  through the node network. No need to involve the miners at all really,
or
  do your suggestion but also report the double spend attempt. By waiting
  maybe 10-60 seconds (instead of 10 minutes for first conf), merchants
can
  be more sure that a double spend attack was not tried. Attacker would
have
  to hold back second tx by 10-60 seconds and hope that that second tx
(with
  higher fee) get's into a solved block before the first one. This forced
  delay time ought to make the attack less successful (but not
impossible).
 

 What prevents the following steps from happening:

 1. attacker sends first transaction, paying to the merchant

 2. merchant waits 10-60 seconds

 3. merchant confirms the payment as received

 4. attacker sees merchant's confirmation

 5. attacker sends double spend

 The security improvement seems to be pretty much exactly the chance
 that during the 10-60 seconds, a block is solved. Am I missing
 something?

 Regarding reporting double spends, this would only help if it comes
 with some kind of penalty for the double spend. Now what if the double
 spend was not done on malicious motives? Maybe someone posted a
 transaction which does not confirm for some reason, and wants to
 recover his funds? Should we regard transactions which do not confirm
 as forever lost, in order to get to an every double spend is a
 misbehaviour policy?

 Best regards,

 Isidor

With 2-of-2 multisignature notaries, the doublespend (the set of
conflicting transactions) would be published and propagated together as
evidence of the notary being malicious. This is trivial and self-evident
self-contained proof.

But there should be no direct penalty IMHO in the Bitcoin protocol itself.

If a transaction would have to be replaced honestly because of being wrong
or simply not confirming, then I think there should be some means of
showing the second transaction is legitimate. Don't ask me how exactly it
would work in practice, but one method could be through showing the
original recipients have signed off on it (showing they agree it should be
reversed).

If you can't get the original recipient to sign, then you're stuck with
either not replacing it or the notary trying to prove the replacing
transaction was legitimate.
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing  Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Time

2014-07-25 Thread Natanael
Probably because the network isn't designed for interactive proofs. Most
interactive algoritms AFAICT requires that some machine holds a secret
state (or at least continuous and untampered state, but you still need to
verify you're falling to the right machine), otherwise the machine can be
mimicked and rewound to earlier states. Without a challenge-response that
can't be faked, you've got problems.

There's no trusted machines here that you can rely on. The certainty of
having the right blockchain is a statistical one over longer periods of
time, not enough for a PIN you want verified right now. So you can always
be shown an old copy, and if your node isn't up to date yet then it can
also be shown fake chains further into the future.

Maybe you could throw in some kind of Secure Multiparty Computation among
the miners to enable challenge-response, with state saved in the blockchain
(so it can't be rolled back), but that would be fragile. How do you select
what nodes may participate? How do you prevent the secret state from
leaking? And performance would be absolutely horrible, and reliability is a
huge problem.
Den 25 jul 2014 18:03 skrev Mike Hearn m...@plan99.net:

 Sorry, you're right. I'd have hoped a delay that doubles on failure each
 time up to some max would be good enough, relying on the p2p network to
 unlock a PIN feels weird, but I can't really quantify why or what's wrong
 with it so I guess it's just me :-)


 On Fri, Jul 25, 2014 at 4:45 PM, Aaron Voisine vois...@gmail.com wrote:

 The problem is if someone moves system time forward between app launches.
 The lockout period doesn't have to be all that precise, it just makes you
 wait for the next block, then 5, then 25, and so on. Using a well
 known time server over https would also be a good option, but the wallet
 app already has the chain height anyway.


 On Friday, July 25, 2014, Mike Hearn m...@plan99.net wrote:

  Given that the speed at which the block chain advances is kind of
 unpredictable, I'd think it might be better to just record the time to disk
 when a PIN attempt is made and if you observe time going backwards, refuse
 to allow more attempts until it's advanced past the previous attempt.


 On Fri, Jul 25, 2014 at 7:56 AM, Aaron Voisine vois...@gmail.com
 wrote:

 It's based on the block height, not the block's timestamp. If you have
 access to the device and the phone itself is not pin locked, then you
 can jailbreak it and get access to the wallet seed that way. A pin
 locked device however is reasonably secure as the filesystem is
 hardware aes encrypted to a combination of pin+uuid. This was just an
 easy way to prevent multiple pin guesses by changing system time in
 settings, so that isn't the weakest part of the security model.

 Aaron Voisine
 breadwallet.com


 On Thu, Jul 24, 2014 at 8:21 PM, William Yager will.ya...@gmail.com
 wrote:
  On Thu, Jul 24, 2014 at 10:39 PM, Gregory Maxwell gmaxw...@gmail.com
 
  wrote:
 
 
  Is breadwallet tamper resistant  zero on tamper hardware? otherwise
  this sounds like security theater I attach a debugger to the
  process (or modify the program) and ignore the block sourced time.
 
 
  It's an iOS application. I would imagine it is substantially more
 difficult
  to attach to a process (which, at the very least, requires root, and
 perhaps
  other things on iOS) than to convince the device to change its system
 time.
 
  That said, the security benefits might not be too substantial.
 
 
 --
  Want fast and easy access to all the code in your enterprise? Index
 and
  search up to 200,000 lines of code with a free copy of Black Duck
  Code Sight - the same software that powers the world's largest code
  search on Ohloh, the Black Duck Open Hub! Try it now.
  http://p.sf.net/sfu/bds
  ___
  Bitcoin-development mailing list
  Bitcoin-development@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 


 --
 Want fast and easy access to all the code in your enterprise? Index and
 search up to 200,000 lines of code with a free copy of Black Duck
 Code Sight - the same software that powers the world's largest code
 search on Ohloh, the Black Duck Open Hub! Try it now.
 http://p.sf.net/sfu/bds
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




 --

 Aaron Voisine
 breadwallet.com




 --
 Want fast and easy access to all the code in your enterprise? Index and
 search up to 200,000 lines of code with a free copy of Black Duck
 Code Sight - the same software that powers the world's largest code
 search on Ohloh, the Black Duck Open Hub! 

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

2015-02-12 Thread Natanael
On Thu, Feb 12, 2015 at 8:52 PM, Justus Ranvier
justusranv...@riseup.net wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 On 02/12/2015 07:47 PM, Allen Piscitello wrote:
 Nothing will stop that.  Bitcoin needs to deal with those issues,
 not stick our heads in the sand and pretend they don't exist out of
 benevolence. This isn't a pet solution, but the rules of the
 protocol and what is realistically possible given the nature of
 distributed consensus.  Relying on altruism is a recipe for
 failure.

 If there's a risk of fire burning down wooden buildings, pass out fire
 extinguishers and smoke detectors, not matches.

 The latter makes one an arsonist.

Controlled fires is a valid tactic when necessary to reduce harm. It
is frequently used in areas with periods of extreme heat including
Australia. By burning off grids, you isolate the majority of flammable
matter into islands. An accident fire would cause much more damage.

Placing yourself in the way of the fire and asking them to find
another solution isn't that bright. It is only a matter of time until
a fire starts, controlled or not! If you want another solution, go
figure one out yourself!

More to the point, it is unreasonable to knowingly expose yourself to
risk of harm and blame everybody else who isn't making your life
easier without you having to change anything. If the majority decides
that the best option to reduce harm for everybody requires that you
move out of the way and find another way to do things, you're better
off moving.

Telling people it is fine to keep being careless when there's a fire
hazard is the real crime, because that would cause more harm than
what those who try to get the system changed does.

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Proposal to address Bitcoin malware

2015-01-31 Thread Natanael
Den 31 jan 2015 23:17 skrev Brian Erdelyi brian.erde...@gmail.com:

 Hello all,

 The number of incidents involving malware targeting bitcoin users
continues to rise.  One category of virus I find particularly nasty is when
the bitcoin address you are trying to send money to is modified before the
transaction is signed and recorded in the block chain.  This behaviour
allows the malware to evade two-factor authentication by becoming active
only when the bitcoin address is entered.  This is very similar to how
man-in-the-browser malware attack online banking websites.

 Out of band transaction verification/signing is one method used with
online banking to help protect against this.  This can be done in a variety
of ways with SMS, voice, mobile app or even security tokens.  This video
demonstrates how HSBC uses a security token to verify transactions online.
https://www.youtube.com/watch?v=Sh2Iha88agE.

 Many Bitcoin wallets and services already use Open Authentication (OATH)
based one-time passwords (OTP).  Is there any interest (or existing work)
in in the Bitcoin community adopting the OATH Challenge-Response Algorithm
(OCRA) for verifying transactions?

 I know there are other forms of malware, however, I want to get thoughts
on this approach as it would involve the use of a decimal representation of
the bitcoin address (depending on particular application).  In the HSBC
example (see YouTube video above), this was the last 8 digits of the
recipient’s account number.  Would it make sense to convert a bitcoin
address to decimal and then truncate to 8 digits for this purpose?  I
understand that truncating the number in some way only increases the
likelihood for collisions… however, would this still be practical or could
the malware generate a rogue bitcoin address that would produce the same 8
digits of the legitimate bitcoin address?

See vanitygen. Yes, 8 characters can be bruteforced.

You need about 100 bits of security for strong security, and at the very
least NOT less than ~64 (see distributed bruteforce projects attacking 64
bit keys for reference, you can find plenty via Google).

You shouldn't rely on mechanisms intended to be used for one-shot auth
where the secret is supposed to be unguessable for another system where the
attacker knows what the target string is and have a fair amount of time to
attempt bruteforce.

Use something more like HMAC instead.
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Proposal to address Bitcoin malware

2015-01-31 Thread Natanael
Den 1 feb 2015 00:05 skrev Brian Erdelyi brian.erde...@gmail.com:

 See vanitygen. Yes, 8 characters can be brute forced.

 Thank you for this reference.  Interesting to see that there is a tool to
generate a vanity bitcoin address.

 I am still researching viruses that are designed to manipulate a bitcoin
address.  I suspect they are primitive in that they use a hardcoded rogue
bitcoin address as opposed to dynamically generating one.

 As a start, this would help protect against malware that uses a static
rogue bitcoin address.  The next thing would be for the malware to
brute-force the legitimate bitcoin address and generate a rogue bitcoin
address that would produce the same 8 digit code.  Curious to know how long
this brute force would take?  Or perhaps, before converting to 8 digits
there is some other hashing function that is performed.

 Brian Erdelyi

To bruteforce 8 decimals, on average you need (10^8)/2 = 50 000 000 tries.
log(50M)/log(2) = 25.6 bits of entropy.

One try = generate a random number, use it to generate an ECDSA keypair,
SHA256 and RIPEMD160 hash the public key per Bitcoin specs, then run that
OCRA hashing code, then compare strings. Considering the ECDSA operations
is by a large margin slower than all the hash functions, consider them to
just add a small percentage in performance drop vs regular vanitygen usage.

My non-gaming laptop performed IIRC at *a few million keys per second* with
OpenCL. I've used it to search for 6 character strings in the base58
Bitcoin addresses with it in 15 minutes to half an hour or so. That's about
35 bits of entropy (rough estimate, there's some details with padding in
the base58 representation that alters it).

So 2^(35-26) ~= 1 in 500 of that time, and that's if you use a laptop
instead of a GPU rig. Seconds at worst. Milliseconds if done on a rig.
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Proposal to address Bitcoin malware

2015-01-31 Thread Natanael
Den 1 feb 2015 00:37 skrev Natanael natanae...@gmail.com:


 To bruteforce 8 decimals, on average you need (10^8)/2 = 50 000 000
tries. log(50M)/log(2) = 25.6 bits of entropy.

Oops. Used the wrong number in the entropy calculation. Add one bit, the
division by 2 wasn't supposed to be used in the entropy calculation.
Doesn't change the equation much, though.
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Standardizing automatic pre-negotiation of transaction terms with BIP70? (Emulating Amazon one-click purchase at all merchants)

2015-02-10 Thread Natanael
BIP70 is a protocol for getting a user's wallet client communicate with a
merchant's server in order to agree on details like where to send the
payment, how much to send, what the shipping address is, sending a receipt
back, and much more using various extensions that adds more functionality.

There could even be advanced functionality for automatically negotiating
terms. One example could be selecting a multisignature arbitrator both
sides trust. Another could be to agree on the speed and type of delivery.
Many more types of decisions could be automatically agreed upon.

But as it is now, it is designed to be initiated at the time of payment. If
you always want next-day delivery from online stores then you won't always
know if that's an option until you've filled the digital basket and gone
through checkout. If you only want to shop with an arbitrator involved same
thing applies.

Everything that BIP70 enables happens at the last step only, as it is right
now.

If there could be a BIP70 HTML tag on web shops that automatically
triggered your wallet as soon as you visit the page, it would be possible
for a browser extension that talks to your wallet to tell you right away if
the web shop you're currently looking at has terms you consider acceptable
or not (note: if your wallet client isn't installed on or linked to that
same machine, a visible Qr code would be an acceptable alternative which
you can scan in advance before you start shopping). This notification can
even be automatically updated as you add and remove things from your cart
and details like shipping options change.

This would massively simplify the shipping experience and make every web
shop feel like Amazon.

Of course this has privacy implications and increases exposure to potential
wallet exploits, but the wallet can ask you if you intend to shop or not at
each site before it even connects and send any information at all in order
to mitigate both of those problems. This way it should be reasonably safe.

Another option would be to automatically connect but limit what data is
sent in order to remain privacy preserving, until the user agrees to send
private information.

This second method would also open up for the merchant to other send
relevant information such as details about various certifications from
third parties, which can include a certification that shows they have been
been audited and approved by by entity X for purpose Y. If your wallet has
that entity whitelisted it will show you that certificate (for example
Acme Audits have audited and approves of Merchant M's privacy policy and
data protection). With a list of predefined types of certifications that
the wallet understand and accepts, it could (by choice of the user) require
a certificate to be present to even allow you to make a purchase (lack of
required certifications would result in automatic denial). No certificate =
your wallet never proceed to send private information.

Thoughts?

- Sent from my tablet
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Standardizing automatic pre-negotiation of transaction terms with BIP70? (Emulating Amazon one-click purchase at all merchants)

2015-02-10 Thread Natanael
Den 10 feb 2015 11:34 skrev MⒶrtin HⒶboⓋštiak martin.habovst...@gmail.com
:

 Why would anyone want to do anything about payment before choosing
 what he wants to buy and for what price? I've never used Amazon but
 isn't filling a form with shipping information enough?

That's not what this is about.

BIP70 isn't just payment, it is about communication the terms of the sale.

Let's say you're visiting an international webshop. But they don't ship to
your country. Wouldn't you want to know that before your start filling the
cart? With this, your wallet / browser extension could tell you right away
that you can't shop there. No time wasted!

That's just one requirement of many where you would benefit from being told
right away if it is acceptable for both parties or not.
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Standardizing automatic pre-negotiation of transaction terms with BIP70? (Emulating Amazon one-click purchase at all merchants)

2015-02-10 Thread Natanael
Den 10 feb 2015 11:48 skrev MⒶrtin HⒶboⓋštiak martin.habovst...@gmail.com
:

 I still don't understand. The website can have this information
 available. This is exactly what e-bay does - it displays shipping
 information to my country before I do anything. What's the problem?

 Also with other stuff, website can do it and browser extension can do
 it too without messing with Bitcoin.

1: IP isn't guaranteed to work correctly both because you might be using a
VPN out Tor.

2: Yes, the site can display all options right away, but are you willing to
read all of them too?

3: Detailed information is not necessary, nor does it have to be
unprompted. It doesn't need to tell you more than which country you are in.
It can even prompt you with a popup that has a slider that shows exactly
how much information and of what kind you're about to share (including
none, if that's your choice).

4: It doesn't need to share raw data. Take a look at anonymous credentials:
http://www.zurich.ibm.com/idemix/
https://eprint.iacr.org/2013/622.pdf

5: It can wait for prompting until you add the first item to the cart.
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Proposal: Requiring a miner's signature in the block header

2015-02-11 Thread Natanael
Den 11 feb 2015 09:55 skrev Hector Chu hector...@gmail.com:

 A proposal for stemming the tide of mining centralisation -- Requiring a
 miner's signature in the block header (the whole of which is hashed), and
 paying out coinbase to the miner's public key.

 Please comment on whether this idea is feasible, has been thought of
before,
 etc., etc. Thank you.

 Motivation
 --

 Mining is centralising to a handful of pool operators. This is bad for a
 number of political reasons, which we won't go into right now. But I have
 always believed that some years down the line, they could hold the users
 hostage and change the rules to suit themselves. For instance by
eliminating
 the halving of the block reward.

[...]

 I propose that we require each miner to sign the block header prior to
 hashing. The signature will be included in the data that is hashed.
Further,
 the coinbase for the block must only pay out to the public key
counterpart of
 the private key used to sign the block header.

[...]

 This will make it difficult to form a cooperating pool of miners who may
not
 trust each other, as the block rewards will be controlled by disparate
parties
 and not by the pool operator. Only a tight clique of trusted miners would
be
 able to form their own private pool in such an environment.

People already trust things like cloud mining, so your solution with
increasing technical trust requirements won't help. But you will however
break P2Pool instead.

Also, note that threshold signatures (group signatures) could probably be
used by an actual distrusting pool's miners. There are already a proof of
concept for this implemented with secp256k1 that works with Bitcoin clients
silently. This wouldn't prevent such a pool from working.
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

2015-02-12 Thread Natanael
Den 12 feb 2015 14:44 skrev Mike Hearn m...@plan99.net:

 You can prove a doublespend instantly by showing two conflicting
transactions both signed by thar party. This pair can be distributed as a
proof of malice globally in seconds via a push messaging mechanism.

 There have been lots of e-cash schemes proposed in the academic
literature that work like this, or variants of it. Schemes where
participants are anonymous until they double spend are popular.

 Let's re-write your proposal but substituting the word notary for miner:

 To profit, the miner would have to be sure the payout from agreeing on
collusion (or to perform the doublespend themselves) would pay out better
than acting honestly for a given amount of time info the future. This means
transactions for small sums are secure.

 That's the exact argument we're having. The assertion is that a
rational notary would kill his own business to increase his profits in
the next few hours. So you're just arguing that a notary is different to a
miner, without spelling out exactly why.

 Does the notary have to make a big up front investment? If so, why is
that different to mining investment?

Miners are transient. You don't depend on any given subset of them.
Centralized e-currency give you no choice but to trust one set of notaries.

The notary don't have any large maintenance costs. The initial investment
is small, they don't need more than a few servers and maybe a HSM and some
office. In the non-collateral version, they're a centralized entity. Note
that in the fully centralized model, if the notary goes bad you're screwed.
Your tokens are useless or maybe gone.

Essentially you can't know if you're up for the long con or not.

Anybody can set up a miner with capital investments. No individual miner
has a large impact on the system as a whole.

In Bitcoin, you aren't dependent on any one multisignature notary. One
going gown only represents a small loss and done temporarily locked funds.
Anybody can set up a multisignature notary, but people won't trust you
unless you show you're trustable - you need to market yourself to get to
the point where a malicious doublespend can be profitable.

You can't really replicate the collateralized multisignature notary model
in centralized systems. Because having the e-currency bank be the notary
means they have the same powers a 51% miner would have - they can block the
transaction claiming the collateral, they can censor any other transactions
at will, and all your funds depend on them and the market's trust in them.

 Is the notary non-anonymous and afraid of being charged with payment
fraud? If so, note that big miners do lots of non-anonymous things too,
like renting warehouses and importing specialised equipment.

As notaries can be small operations, they can perform the doublespend as
they escape across the border.

 Is it because of the big up front collateral they're meant to have lying
around? If so, how do you ensure a fluid market for notaries?

With collateralized multisignature notaries, my assumption is that
organizations that are related to Bitcoin transactions that has sufficient
sums of unallocated funds would use them for collateral in a scheme like
this (almost every large organization in the world have some unallocated
funds somewhere).

As sellers have almost no risk of losing money to them, any notary backed
by somebody they know and trust would be good enough

As buyers also have no risk, they'd use them when they want to make quick
payments.

-

You seem to be making a lot of arguments from the status quo. I don't care
what people have been doing, preserving every habit isn't a sacred goal. I
care about stable incentives and long term predictability regarding what
behavior is safe. Behavior that becomes unsafe if incentives change is bad
and shouldn't be relied on.

Also, Bitcoin is the concensus mechanism. As mentioned, trying to provide a
guarantee for what will end up in the blocks without servers involved is to
reinvent Bitcoin within Bitcoin. I can go Xzibit on you all day long if you
like!  What you consider an attack is irrelevant. You assume a certain
behavior is desired without first making sure it is reliable.

Depending on that which isn't guaranteed is bd, and breaking other
people's assumptions is by itself NOT an attack if there never was a
guarantee or even as little as an implicit understanding it is safe.

Your also assume people will expect the Bitcoin network to keep zero-conf
safe forever and that Bitcoin valuation is tied to that. Given the options
available and current state of things, I'm assuming that's wrong.

Besides, zero-conf will never be secure if you don't add external
contextual information as a requirement when validating blocks. Otherwise
defecting miners will frequently doublespend against you. And adding such
information is messy and probably not secure in itself, as it opens up for
gaming the system through network level attacks.

And your remarks 

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

2015-02-12 Thread Natanael
Den 12 feb 2015 13:49 skrev Mike Hearn m...@plan99.net:

 Are you not counting collateralized multisignature notaries? Its an
extended version of the Greenaddress.it model.

 It makes unconfirmed transactions useless in the classical Bitcoin model.
Obviously if you introduce a trusted third party you can fix things, but
then you're back to having the disadvantages of centralised trust.

That trust you put in them is extremely limited, and temporary.

First of all, the standard multisignature notary model applies like how I
originally described it in my blog post over a year ago.

You can prove a doublespend instantly by showing two conflicting
transactions both signed by thar party. This pair can be distributed as a
proof of malice globally in seconds via a push messaging mechanism.

After confirmation in the blockchain, you have standard Bitcoin transaction
security.
To profit, the notary would have to be sure the payout from agreeing on
collusion (or to perform the doublespend themselves) would pay out better
than acting honestly for a given amount of time info the future. This means
transactions for small sums are secure.

To provide security for high value transactions, NRW adds a collateral
transaction that the notary stands for and signs in advance, and gives to
the seller. The key here is that it is constructed such that if the
original payment gets doublespent, then this collateral transaction to the
seller becomes spendable.

So there is two outcomes - either the customer or the notary pays the
seller. The customer can't force a doublespend. The notary can't steal or
freeze funds (due to nlocktime fund recovery option). The seller knows
he'll get the funds for sure before delivering the goods. Nobody is at
risk.
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

2015-02-12 Thread Natanael
Den 12 feb 2015 12:58 skrev Mike Hearn m...@plan99.net:
[...]

 Your scorched earth plan is aptly named, as it's guaranteed to make
unconfirmed payments useless.

Are you not counting collateralized multisignature notaries? Its an
extended version of the Greenaddress.it model.

NoRiskWallet: https://github.com/baleato/bitcoin-hackathon
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

2015-02-12 Thread Natanael
Den 12 feb 2015 15:53 skrev Mike Hearn m...@plan99.net:

  So you're just arguing that a notary is different to a miner, without
spelling out exactly why.

 I'm afraid I still don't understand why you think notaries would build
long term businesses but miners wouldn't, in this model.

 I think you are saying because notaries have identity, brand awareness
and because they have big up front bonds, that means they will be
trustworthy.

Miners aren't contractors, they don't have to care about repeat business.
Individual miners don't have enough impact to have a negative impact on
their own capital investment. Zero-conf transactions also aren't that tied
to the Bitcoin valuation.

Multisignature notaries need to convince people to select them. They want
to know that even with collateral, their funds won't be temporarily locked
up and unspendable for days at a time.

What services would miners provide here, do you think?

 Well, sure. It's the same model governments use and is why being a money
transmitter in the USA is so difficult: you need to put up large sums of
money as collateral and have your fingerprints taken 48 times. Then you can
start advertising to get customers!

Obviously you need to have collateral to provide collateral. Can't make
cryptographic verifiable guarantees if you don't have the resources to back
them.

 The reason mining is such a nice model is it doesn't have these sorts of
requirements.

And also can't make these assurances. Any minority miner can be overrun.

 As notaries can be small operations . [snip] .. (almost every
large organization in the world have some unallocated funds somewhere).

 Which is it? Are notaries small operations or large operations?

The operation itself is small. A few people maintaining a few servers.

The collateral needed depends on how many and how large simultaneous
transactions they want to provide assurances for, so they can chose to be a
small player for one niche market or large and global if they have the
funds for it.

 I think exploring new consensus models with semi-trusted notaries is
interesting, but it's not Bitcoin.

Methods for decentralized consensus that aren't PoW also aren't Bitcoin.

 Please don't try and apply this logic in the real world :( Rephrased:

 That's a nice house. I noticed it's made of wood. I'm going to start
fires until it burns down, because there is no guarantee your house won't
burn down in future and it's important you understand that wooden houses
aren't safe. Really I'm just doing you a favour.

Actually that IS often a bad idea. But fortunately the risk and threat is
low, and mitigation is well understood.

 I'm really not a fan of Peter's approach, which is hey let's try and
cause as many problems as possible to try and prove a point, without having
created any solutions. Replace-by-fee-scorched-earth doesn't work and
isn't a solution. Miners can easily cut payment fraudsters in on the stolen
money, and as they'd need to distribute custom double-spending wallets to
make the scheme work it'd be very easy to do.

Security analysis requires having the mindset of an attacker. Sometimes
that reveals suboptimal choices. Then you want them changed to more stable
choices such that once the incentives change, the risk already is gone.
Minimization of damage, simply put.

 Your also ssume people will expect the Bitcoin network to keep zero-conf
safe forever and that Bitcoin valuation is tied to that. Given the options
available and current state of things, I'm assuming that's wrong.

 Why? You think ability to make payments in a few seconds is some
irrelevant curiousity?

No. But you can't be certain it is secure without having a solid reliable
mechanism to provide such a guarantee.

You want zero-conf to stay safe without involvement of servers? Then
please, try to find a way to secure it. Right now you're assuming it can
remain safe based on circumstances which can change and assumptions about
market participant's valuations that likely aren't true.

 Let's put it this way. If BitPay's business model evaporates tomorrow,
along with all the merchants they support, do you think that'd have any
effect on Bitcoin's value? If not, why not?

It would. They'd tank. But you're assuming too much about the basis for
valuation.
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

2015-02-12 Thread Natanael
Den 12 feb 2015 16:15 skrev Mike Hearn m...@plan99.net:

 The first is that this setup means miners can steal arbitrary payments if
they work together with the sender of the money. The model assumes this
collaboration won't happen, but it will. Because no existing wallet has a
double spend this button, to make the scheme work the dishonest miners
must create and distribute such a wallet that implements the whole
scorched-earth protocol. At that point it's easy for miners to reward the
payment fraudster with some of the stolen money the merchant lost, meaning
it now makes sense for the fraudster to always do this. The situation isn't
stable at all.

 The second is that it incentivises competitors to engage in payment fraud
against each other. A big rich coffee shop chain that is facing competition
from a small, scrappy newcomer can simply walk into the new shop and buy
things, then trigger the scorched earth. Even with no miner
collaboration, this means the big company is down the cost of the product
but so is the little company who lost everything. Whoever can outspend the
other wins.

 We don't really need game theory to tell us that this plan is a bad idea.
Just imagine trying to explain it to an actual shop keeper. They would
think you were crazy. Bitcoin is already a hard enough concept to
understand without throwing into the mix anyone can burn the money they
gave you after walking out of the shop.

I see no fundamental difference in outcome from miner collusion in
scorched-fee (which isn't guaranteed to pay the right pool!) and miner
collusion in knowingly mining a doublespend transaction.

Both outcomes pay the miner and thief equally when successful. The merchant
loses in both.

Zero-conf needs something else for security. A guarantee it can not be
doublespent in the relevant time frame.
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

2015-02-12 Thread Natanael
Den 12 feb 2015 16:42 skrev Mike Hearn m...@plan99.net:
 Remember that you aren't paying the bad pool, the bad pool is paying you.
Whichever pool benefits from the scorched earth protocol can simply pick an
address out of the transaction it perceived as starting the protocol, and
pay that.

My counterargument: with zero-conf but no replace-by-fee scorched earth,
there would instead be a market which thieves use where pools would offer
to execute doublespends that pay the thief and the pool, and where the
pools would set what terms and payouts they ask for.

All bidding pools with acceptable terms get a doublespend transaction that
pays that specific pool and the thief, the first to mine theirs win (and
the merchant loses).

Your protocol requires less setup, but that's the only notable difference
(besides risk of paying non-participating pools with scorched earth).

No notable difference in security for merchants.
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Are Instant Confirmations safe?

2015-03-18 Thread Natanael
Den 18 mar 2015 23:38 skrev Dennis Sullivan dennis.jm.sulli...@gmail.com
:

 Hello. This is my first time posting to this list. I wanted to ask your
opinions on something relating to confirmation times.

 I recently read about a transaction locking proposal which claims to
make it possible to accept 0-conf transactions with guarantee they will get
mined. This seems rather dubious to me, because if there was merit to the
system, I would have already expected to see discussion on this list
regarding it.

Sounds like it would be weak to sybil attacks (deterministically choosing
my own nodes sounds great!), and of course Finney attacks (single-block
reversal) and defecting miners (what are you gonna do, punish miners with
limited network connectivity as well? You'll risk forking the network).

Zero-conf is only safe if nobody's actively trying to attack you. It has no
inherent security in and of itself. For low values the risk is usually
tolerated. For large values there's too much risk of making yourself a
target.
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] bip44 GPG identities - POC demo

2015-03-08 Thread Natanael
Den 8 mar 2015 02:36 skrev Pavol Rusnak st...@gk2.sk:

 On 07/03/15 16:53, Mem Wallet wrote:
[...]
 I am currently in process of implementing a SignIdentity message for
 TREZOR, which will be used for HTTPS/SSH/etc. logins.

 See PoC here:

https://github.com/trezor/trezor-emu/commit/9f612c286cc7b8268ebaec4a36757e1c19548717

 The idea is to derive the BIP32 path from HTTPS/SSH URI (by hashing it
 and use m/46'/a'/b'/c'/d' where a,b,c,d are first 4*32 bits of the hash)
 and use that to derive the private key. This scheme might work for GPG
 keys (just use gpg://u...@host.com for the URI) as well.

Reminds me of FIDO's U2F protocol.

http://fidoalliance.org/specifications
https://www.yubico.com/products/yubikey-hardware/fido-u2f-security-key/

It ties into the browser SSL session to make sure only the correct server
can get the correct response for the challenge-response protocol, so that
credentials phishing is blocked and worthless. A unique keypair is
generated for each service for privacy, so that you can't easily be
identified across services from the usage of the device alone (thus safe
for people with multiple pseudonyms).
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Proof of Payment

2015-03-13 Thread Natanael
Den 13 mar 2015 20:57 skrev Kalle Rosenbaum ka...@rosenbaum.se:

 Hi all,

 I've been thinking about how a person can prove that she has made a
payment. I came up with an idea I call Proof of Payment (PoP) and I would
highly appreciate your comments. Has something like this been discussed
somewhere before?

 Use cases

 There are several scenarios in which it would be useful to prove that you
have paid for something. For example:
 A pre-paid hotel room where your PoP functions as a key to the door.
 An online video rental service where you pay for a video and watch it on
any device.
 An ad-sign where you pay in advance for e.g. 2-weeks exclusivity. During
this period you can upload new content to the sign whenever you like using
PoP.
 A lottery where all participants pay to the same address, and the winner
of the T-shirt is selected among the transactions to that address. You
exchange the T-shirt for a PoP for the winning transaction.

 These use cases can be achieved without any personal information (no
accounts, no e-mails, etc) being involved.

 Desirable properties:
 A PoP should be generated on demand.
 It should only be usable once to avoid issues due to theft.
 It should be able to create a PoP for any payment, regardless of script
type (P2SH, P2PKH, etc.).

Relevant: https://idemix.wordpress.com/

Anonymous Credentials allows an issuer to declare that you have certain
rights. For example, upon paying the service provider could issue you the
credentials for using their service up until a certain date.

When challenged to prove a statement about what credentials you have, you
can prove the fact that you've got the right credentials without revealing
anything else. You don't even reveal you're the same person as the last
time, if you prove the right to access a VPN multiple times there's no data
in it that links the different sessions together.

The main difference is that issuance of Anonymous Credentials aren't
atomic with the payment transactions, which can open up the risk for
certain types of dishonest behavior by the seller. You could however use a
proof in court of having paid for the credentials but not getting them
issued to you (maybe throw in usage of Factom to log issuance of
credentials?). With this construction of using both these methods, you add
stronger privacy for the usage of the services while simultaneously keeping
a degree of accountability for the payment.

The Zerocoin developers also got a paper on a blockchain version,
Distributed Anonymous Credentials.
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Electrum 2.0 has been tagged

2015-03-12 Thread Natanael
Den 12 mar 2015 19:52 skrev Andreas Schildbach andr...@schildbach.de:

 I'm afraid this will never fly. Wallets are just too different and
 that's a good thing! For example, by design choice Bitcoin Wallet and
 bitcoinj doesn't support multiple accounts. How would it ever import
 wallets from MultiBit or Mycelium?

I think I covered that with the importing wallet says what sections it
supports part. Then you'd only ask for the library to give you the
addresses from the first branch in the main HD wallet. The user would be
told that you by design can't manage the other parts. The user would be
alerted and get the recommendation to send the funds over manually if they
want to switch their wallet. The user might however just want to export
that one single branch if he's a power user, so he would proceed to use
it that way.

At export, I recommend the wallet will tell the user what extensions and
standards are in use (and which are necessary to recover how much of their
funds in the target wallet). The user would be asked to confirm that the
target wallet client supports these. The user should be given the option to
hand the list of supported functionality in the target wallet (like a list
of BIP numbers?), and tell the wallet to move the funds around so that the
target wallet can successfully import everything and recover all funds.

Actually, thinking about it I think what we really need first is a standard
synchronization / transition protocol. Right now we don't have more than
the address label syncing plugin for Electrum. We need something for
wallets to synchronize state, with the option for having one wallet tell
the other how to send over all funds (for when they use completely
different standards for managing funds). As the most simple option, the
target wallet would provide a list of addresses to the sending wallet when
you switch (this would satisfy Bryan's request).
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Electrum 2.0 has been tagged

2015-03-12 Thread Natanael
Den 12 mar 2015 17:48 skrev Mike Hearn m...@plan99.net:

 b) Creation date is just a short-term hack.


 I agree, but we need things to be easy in the short term as well as the
long term :)

 The long term solution is clearly to have the 12 word seed be an
encryption key for a wallet backup with all associated metadata. We're
heading in that direction one step at a time. Unfortunately it will take
time for wallets to start working this way, and all the pieces to fall into
place. Restoring from the block chain will be a semi regular operation for
users until then.

This have been mentioned a few times before, and what I think is necessary
is to create a common file format that can be interpreted by a library
which all wallets can use. I see it as similar as the work to create
libconsensus for parsing the blockchain.

We need something extensible that can describe how to derive all addresses
used by the user. What HD branches to derive and how, with block numbers
(or bloom filters of block hashes or similar) to note where all previously
known transactions related to the wallet have occurred, and the last known
block (so only new blocks need to be scanned).

A way to describe one HD tree as a multisignature wallet tied to a hardware
wallet if you have that (could include serial number or MAC of the device
for simple identification by the wallet client). A way to describe another
set of addresses as using a custom extension. A way to denote one private
key as being used for stealth addresses together with details for how to
identify the transactions (prefix, mailbox to look in, etc). Labels for
transactions. P2SH script templates so those addresses can be recovered. A
way to describe Copay style multisignature wallets and what server to use
for coordinating with the other coowners. A way to describe threshold
crypto group signature wallets and how to coordinate. Computer parsable
descriptions of HD branches as change addresses, as being used for
receiving payments in merchant payment systems, etc... Also, you should
really be talking to people like accountants and auditors to see what
features they'd like to see when it comes to things like how company
wallets could have rules defined for how to use the various HD branches.

And so on... I think you get my point by now.

The basic idea is that the wallet uses the library to parse the wallet file
and tells the user which sections it understands (can't expect all wallets
to handle custom extensions or stealth addresses, etc), then proceeds to
scan the blockchain for those addresses. Then the user also won't be
surprised that not all funds are found and won't think they're lost.

I think it should be referred to as an import/export format, more than as a
backup format.

You always want the most recent metadata the wallet of origin can provide
when importing, to reduce unnecessary extra work. You don't want really old
backup files. If people add new seeds and various new extensions that can't
be automatically recovered from old wallet backups, they need new backups.
You might as well use the wallet's own internal formats for backup, as the
wallet developer might better know how to optimize for the use cases he
have designed for. But at the same time we should ask wallet developers to
offer conversion tools to generate export format files from custom wallet
data files.
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)

2015-02-22 Thread Natanael
Den 22 feb 2015 13:36 skrev Peter Todd p...@petertodd.org:
 Implementing it as a general purpose scripting language improvement has
 a lot of advantages, not least of which is that you no longer need to
 rely entirely on inherently unreliable P2P networking: Promise to never
 create two signatures for a specific BIP32 root pubkey and make
 violating that promise destroy and/or reallocate a fidelity bond whose
 value is locked until some time into the future. Since the fidelity bond
 is a separate pool of funds, detection of the double-spend can happen
 later.

Somebody sent me a zero-confirmation transaction, or one that got orphaned
after one block. I created a transaction spending that UTXO, and another.

So at that point I have UTXO_orphaned based on the sender's UTXO_origin and
my UTXO_old (because I've had it unspent for a long time), both in one
transaction, creating UTXO_new.

Now he doublespend UTXO_origin to create a UTXO_doublespend (which
conflicts with UTXO_orphaned). He conspires with a miner to get it into a
block.

Now what? Can my UTXO_old effectively be tainted forever because UTXO_new
got invalidated together with UTXO_orphaned? Will that transaction be a
valid proof of doublespend against a new UTXO_replacement I created?

Or otherwise, if only transactions where all UTXO's are currently valid
works as doublespend proofs, aren't you still just left without protection
against any one miner that conspires with doublespend attempting thieves?

In other words, you are unprotected and potentially at greater risk if you
create a transaction depending on another zero-confirmation transaction.
--
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=190641631iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)

2015-02-22 Thread Natanael
Den 22 feb 2015 14:29 skrev Natanael natanae...@gmail.com:


 Den 22 feb 2015 13:36 skrev Peter Todd p...@petertodd.org:

  Implementing it as a general purpose scripting language improvement has
  a lot of advantages, not least of which is that you no longer need to
  rely entirely on inherently unreliable P2P networking: Promise to never
  create two signatures for a specific BIP32 root pubkey and make
  violating that promise destroy and/or reallocate a fidelity bond whose
  value is locked until some time into the future. Since the fidelity bond
  is a separate pool of funds, detection of the double-spend can happen
  later.

 Somebody sent me a zero-confirmation transaction, or one that got
orphaned after one block. I created a transaction spending that UTXO, and
another.

 So at that point I have UTXO_orphaned based on the sender's UTXO_origin
and my UTXO_old (because I've had it unspent for a long time), both in one
transaction, creating UTXO_new.

 Now he doublespend UTXO_origin to create a UTXO_doublespend (which
conflicts with UTXO_orphaned). He conspires with a miner to get it into a
block.

 Now what? Can my UTXO_old effectively be tainted forever because UTXO_new
got invalidated together with UTXO_orphaned? Will that transaction be a
valid proof of doublespend against a new UTXO_replacement I created?

 Or otherwise, if only transactions where all UTXO's are currently valid
works as doublespend proofs, aren't you still just left without protection
against any one miner that conspires with doublespend attempting thieves?

 In other words, you are unprotected and potentially at greater risk if
you create a transaction depending on another zero-confirmation transaction.

Additional comments:

If you punish the creation of UTXO_replacement, you will punish people who
was lead to think zero-confirmation transactions were safe and thus that
chains of zero-confirmation transactions also were safe.

If you don't, but STILL accept chains of zero-confirmation transactions
were not all of them are covered by fidelity bonds, then you failed to
protect yourself against thieves who creates chains of unconfirmed
transactions.

Another question: if all transactions in the chain are covered by fidelity
bonds for their own value, which one pays out to who? Does only the first
one pay out, and only to the last party in the chain? Or to every
subsequent party after him? In full or just a fraction? Why, why not? You
might not know which of these serviced their customers in full without
getting full value back in exchange due to the doublespend.

What if the fidelity bond is too small, do you stop accepting it as a
zero-confirmation transaction?

Do you even accept chains of unconfirmed transactions at all?
--
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=190641631iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)

2015-02-22 Thread Natanael
Den 22 feb 2015 17:00 skrev Justus Ranvier justusranv...@riseup.net:

 On 02/22/2015 07:50 AM, Matt Whitlock wrote:
  This happened to one of the merchants at the Bitcoin 2013
  conference in San Jose. They sold some T-shirts and accepted
  zero-confirmation transactions. The transactions depended on other
  unconfirmed transactions, which never confirmed, so this merchant
  never got their money.
 
  I keep telling people not to accept transactions with zero
  confirmations, but no one listens.

 A better solution is to track the failure rate of zero confirmation
 transactions, and adjust prices accordingly to cover the expected loss.

 This is what every merchant *already does* since no payment method has
 a 0% fraud rate.

 Even physical cash has a probability of being counterfeit, and the
 prices you pay for things at a convenience store already have that
 risk priced in.

 The idea that zero confirmation transactions require a 100% guarantee
 is a strawman, especially since there exists no number of
 confirmations the actually produce a 100% irreversibility guarantee.

The problem with this approach is that it is worthless as a predictor. We
aren't dealing with traffic safety and road design - we are dealing with
adaptive attackers and malicious miners and pools.

Anything which does not invalidate blocks carrying doublespends WILL allow
malicious miners and pools to conspire with thieves to steal money. The
probability of being hit will then be (their proliferation in your business
area) * (their fraction of the mining power).

That might seem to give small numbers for most sets of reasonable
assumptions. But the problem is that's only an average, and the people
being hit might have small profit margins - one successful attack can place
hundreds of merchants in red numbers and force them to shut down.

You should never expose yourself to attacks which you can't defend against
and which can be fatal. In particular not if there's nothing in the
environment that is capable of limiting the size or numbers of any attacks.
And there's no such thing today in Bitcoin.

This is why I sketched out the multisignature notary approach, and why some
decided to extend that approach with collateral (NoRiskWallet) to further
reduce trust in the notary. This is the single most practical approach I
know of today to achieve ACTUAL SECURITY for unconfirmed transactions.

Don't like it? See if you can do better!

Just don't rely on zero-confirmation transactions!
--
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=190641631iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)

2015-02-22 Thread Natanael
- Sent from my tablet
Den 22 feb 2015 17:25 skrev Justus Ranvier justusranv...@riseup.net:

 You just disproved your own argument.

 It is possible to predict risk, and therefore to price the risk.

Your fault is that you assume the predictions can be reliable and
trustable.

They can not be.

The data you have available has none of the indicators you actually NEED to
make predictions. You're making extrapolations from the past, not
calculations based on recent trends and behavior globally.

 You also noted that for some Bitcoin users, the price of that risk is
 too high for the types of transactions in which wish to engage.

 In what way does that translated into a universal requirement for
 everybody to use multisignature notaries?

It isn't universal. It is just the most practical solution if you need
instant confirmation for high value transactions with customers you don't
yet trust.

 Surely the users who can afford the risk can use zero conf if they
 like, and those who can't can use multisig notaries?

Use whatever you want. I don't care. I will warn you about the risks and
make suggestions, but I won't force you to do anything differently.
--
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=190641631iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

2015-02-23 Thread Natanael
Den 23 feb 2015 08:38 skrev Andy Schroder i...@andyschroder.com:

 I agree that NFC is the best we have as far as a trust anchor that you
are paying the right person. The thing I am worried about is the privacy
loss that could happen if there is someone passively monitoring the
connection. So, in response to some of your comments below and also in
response to some of Eric Voskuil's comments in another recent e-mail:

From the sources I can find NFC don't provide full privacy, but some
modulations are MITM resistant to varying degrees, some aren't at all, and
they are all susceptible to denial of service via jammers.

If the merchant system monitors the signal strength and similar metrics, a
MITM that alters data (or attempts to) should be detectable, allowing it to
shut down the connection.

Using NFC for key exchange to establish an encrypted link should IMHO be
secure enough.

http://resources.infosecinstitute.com/near-field-communication-nfc-technology-vulnerabilities-and-principal-attack-schema/
--
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=190641631iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development