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

2014-04-22 Thread Matt Whitlock
On Tuesday, 22 April 2014, at 10:06 am, Jan Møller wrote:
 This is a very useful BIP, and I am very much looking forward to
 implementing it in Mycelium, in particular for bip32 wallets.
 To me this is not about whether to use SSS instead of multisig
 transactions. In the end you want to protect a secret (be it a HD master
 seed or a private key) in such a way that you can recover it in case of
 partial theft/loss. Whether I'll use the master seed to generate keys that
 are going to be used for multisig transactions is another discussion IMO.
 
 A few suggestions:
  - I think it is very useful to define different prefixes for testnet
 keys/seeds. As a developer I use the testnet every day, and many of our
 users use it for trying out new functionality. Mixing up keys meant for
 testnet and mainnet is bad.

A fair point. I'll add some prefixes for testnet.

  - Please allow M=1. From a usability point of view it makes sense to allow
 the user to select 1 share if that is what he wants.

How does that make sense? Decomposing a key/seed into 1 share is functionally 
equivalent to dispensing with the secret sharing scheme entirely.

 I have no strong opinions of whether to use GF(2^8) over Shamir's Secret
 Sharing, but the simplicity of GF(2^8) is appealing.

I'll welcome forks of my draft BIP. I don't really have the inclination to 
research GF(2^8) secret sharing schemes and write an implementation at the 
present time, but if someone wants to take my BIP in that direction, then okay.

--
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] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

2014-04-22 Thread Gregory Maxwell
On Tue, Apr 22, 2014 at 1:06 AM, Jan Møller jan.mol...@gmail.com wrote:
 This is a very useful BIP, and I am very much looking forward to
 implementing it in Mycelium, in particular for bip32 wallets.

I haven't seen commentary from you on the Kogelman draft, it would be
helpful there: https://bitcointalk.org/index.php?topic=258678.0

--
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] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

2014-04-22 Thread Jan Møller


   - Please allow M=1. From a usability point of view it makes sense to
 allow
  the user to select 1 share if that is what he wants.

 How does that make sense? Decomposing a key/seed into 1 share is
 functionally equivalent to dispensing with the secret sharing scheme
 entirely.


I agree that it may look silly to have just one-of-one share from a
technical point of view, but from an end-user point of view there could be
reasons for just having one piece of paper to manage. If M can be 1 then
the software/hardware doesn't have to support multiple formats,
import/export paths + UI  (one for SIPA keys in one share, one for HD seeds
in one share, one for SIPA keys + HD seeds in multiple shares).

Less complexity  more freedom of choice.
--
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] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

2014-04-22 Thread Tamas Blummer
Extra encoding for testnet is quite useless complexity in face of many alt 
chains.
BIPS should be chain agnostic.

Regards,

Tamas Blummer
http://bitsofproof.com

On 22.04.2014, at 10:35, Matt Whitlock b...@mattwhitlock.name wrote:

 On Tuesday, 22 April 2014, at 4:11 am, Matt Whitlock wrote:
 On Tuesday, 22 April 2014, at 10:06 am, Jan Møller wrote:
 - I think it is very useful to define different prefixes for testnet
 keys/seeds. As a developer I use the testnet every day, and many of our
 users use it for trying out new functionality. Mixing up keys meant for
 testnet and mainnet is bad.
 
 A fair point. I'll add some prefixes for testnet.
 
 Testnet encodings are added: 
 https://github.com/whitslack/btctool/blob/bip/bip-.mediawiki
 
 --
 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
 



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
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] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

2014-04-22 Thread Jan Møller
Necessary Shares = M+1, not a problem

I would probably encode N-of-M in 1 byte as I don't see good use cases with
more than 17 shares. Anyway, I am fine with it as it is.


On Tue, Apr 22, 2014 at 10:29 AM, Matt Whitlock b...@mattwhitlock.namewrote:

 On Tuesday, 22 April 2014, at 10:27 am, Jan Møller wrote:
 - Please allow M=1. From a usability point of view it makes sense to
   allow
the user to select 1 share if that is what he wants.
  
   How does that make sense? Decomposing a key/seed into 1 share is
   functionally equivalent to dispensing with the secret sharing scheme
   entirely.
  
  
  I agree that it may look silly to have just one-of-one share from a
  technical point of view, but from an end-user point of view there could
 be
  reasons for just having one piece of paper to manage. If M can be 1 then
  the software/hardware doesn't have to support multiple formats,
  import/export paths + UI  (one for SIPA keys in one share, one for HD
 seeds
  in one share, one for SIPA keys + HD seeds in multiple shares).
 
  Less complexity  more freedom of choice.

 Alright. It's a fair argument. Do you agree with encoding M using a bias
 of -1 so that M up to and including 256 can be encoded in one byte?

--
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] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

2014-04-22 Thread Jan Møller
I am concerned about space, but more about usability :-)
 I'll definitely use both M and the checksum.


On Tue, Apr 22, 2014 at 10:43 AM, Matt Whitlock b...@mattwhitlock.namewrote:

 On Tuesday, 22 April 2014, at 10:39 am, Jan Møller wrote:
  Necessary Shares = M+1, not a problem
 
  I would probably encode N-of-M in 1 byte as I don't see good use cases
 with
  more than 17 shares. Anyway, I am fine with it as it is.

 I agree that M  16 is probably not a viable use case for human beings,
 but machines would probably be able to make use of it. I, for one, welcome
 our new robot overlords.

 Also, the byte that encodes M−1 is optional, so if you're concerned about
 space, you can omit it (and the checksum).

--
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] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

2014-04-22 Thread Tamas Blummer
I do not suggest to encode the chain, in contrary.

I consider the encoding of main and testnet in WIF and BIP32 as legacy, that I 
ignore, and suggest that new BIPs should no longer carry this forward.

Regards,

Tamas Blummer
http://bitsofproof.com



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
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] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

2014-04-22 Thread Matt Whitlock
On Tuesday, 22 April 2014, at 10:39 am, Tamas Blummer wrote:
 Extra encoding for testnet is quite useless complexity in face of many alt 
 chains.
 BIPS should be chain agnostic.

I would argue that Bitcoin should be altcoin-agnostic. :)

I have no interest in catering to altcoins. But that's just me.

--
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] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

2014-04-22 Thread Jan Møller
I did comment on it back in october (
https://bitcointalk.org/index.php?topic=258678.msg3298089#msg3298089) :-)
But I must admit that I haven't been tracking it since then.

I have never been a proponent of BIP 38 (which this BIP is derived from)
and generally think that encrypting a secret with a human generated
password is silly for many reasons (Let me know if I should repeat my list
of concerns). As far as I remember we are pretty much on the same page here.
Using SSS is superior in every way that I can think of.


On Tue, Apr 22, 2014 at 10:15 AM, Gregory Maxwell gmaxw...@gmail.comwrote:

 On Tue, Apr 22, 2014 at 1:06 AM, Jan Møller jan.mol...@gmail.com wrote:
  This is a very useful BIP, and I am very much looking forward to
  implementing it in Mycelium, in particular for bip32 wallets.

 I haven't seen commentary from you on the Kogelman draft, it would be
 helpful there: https://bitcointalk.org/index.php?topic=258678.0

--
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] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

2014-04-22 Thread Matt Whitlock
On Tuesday, 22 April 2014, at 10:39 am, Jan Møller wrote:
 On Tue, Apr 22, 2014 at 10:29 AM, Matt Whitlock b...@mattwhitlock.namewrote:
  On Tuesday, 22 April 2014, at 10:27 am, Jan Møller wrote:
  - Please allow M=1. From a usability point of view it makes sense to 
 allow
 the user to select 1 share if that is what he wants.
   
How does that make sense? Decomposing a key/seed into 1 share is
functionally equivalent to dispensing with the secret sharing scheme
entirely.
   
   I agree that it may look silly to have just one-of-one share from a
   technical point of view, but from an end-user point of view there could be
   reasons for just having one piece of paper to manage. If M can be 1 then
   the software/hardware doesn't have to support multiple formats,
   import/export paths + UI  (one for SIPA keys in one share, one for HD 
   seeds
   in one share, one for SIPA keys + HD seeds in multiple shares).
  
   Less complexity  more freedom of choice.
 
  Alright. It's a fair argument. Do you agree with encoding M using a bias
  of -1 so that M up to and including 256 can be encoded in one byte?
 
 Necessary Shares = M+1, not a problem
 
 I would probably encode N-of-M in 1 byte as I don't see good use cases with
 more than 17 shares. Anyway, I am fine with it as it is.

Encoding bias of M changed to -1, and test vectors updated:
https://github.com/whitslack/btctool/blob/bip/bip-.mediawiki

--
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] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

2014-04-22 Thread Justin A
Is there a reason you prefer doing the M-1 offset as opposed to limiting
the range to 255 instead? Seems like something that will certainly confuse
some developers in exchange for adding one more value at the high end of a
range. I don't gather there's much difference between 255 and 256 here is
there? Also requires the small bit of explanation to hang around as a rider
in all future documentation, and the name of the field may not be
self-documenting anymore.

By way of predicting how I'm wrong, perhaps it is better to have a field
where all possible values are legitimate (by not biasing you would have to
check it's not zero), or perhaps it's important that powers of 2 be
represented here? Perhaps there's some use case at 256 that 255 just won't
do for?

I'm mostly just curious, as I find problems and funnies crop up when people
get clever with optimization of things like message bit-packing etc.. If
it's not necessary then maybe better to keep to what's intuitive (i.e. the
girls name is clear and self-documenting)

Anyway enough of my bike shedding!
On Apr 22, 2014 5:38 AM, Matt Whitlock b...@mattwhitlock.name wrote:

 On Tuesday, 22 April 2014, at 10:39 am, Jan Møller wrote:
  On Tue, Apr 22, 2014 at 10:29 AM, Matt Whitlock b...@mattwhitlock.name
 wrote:
   On Tuesday, 22 April 2014, at 10:27 am, Jan Møller wrote:
   - Please allow M=1. From a usability point of view it makes
 sense to allow
  the user to select 1 share if that is what he wants.

 How does that make sense? Decomposing a key/seed into 1 share is
 functionally equivalent to dispensing with the secret sharing
 scheme
 entirely.

I agree that it may look silly to have just one-of-one share from a
technical point of view, but from an end-user point of view there
 could be
reasons for just having one piece of paper to manage. If M can be 1
 then
the software/hardware doesn't have to support multiple formats,
import/export paths + UI  (one for SIPA keys in one share, one for
 HD seeds
in one share, one for SIPA keys + HD seeds in multiple shares).
   
Less complexity  more freedom of choice.
  
   Alright. It's a fair argument. Do you agree with encoding M using a
 bias
   of -1 so that M up to and including 256 can be encoded in one byte?
 
  Necessary Shares = M+1, not a problem
 
  I would probably encode N-of-M in 1 byte as I don't see good use cases
 with
  more than 17 shares. Anyway, I am fine with it as it is.

 Encoding bias of M changed to -1, and test vectors updated:
 https://github.com/whitslack/btctool/blob/bip/bip-.mediawiki


 --
 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] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

2014-04-22 Thread Nikita Schmidt

 A fair point. I'll add some prefixes for testnet.


I've looked at the latest draft and am worried about the increased AVB
namespace usage.  Would it make sense to differentiate main/testnet in
the prefix byte instead of the AVB?  Perhaps aiming for ST rather than
TS.

 I'll welcome forks of my draft BIP. I don't really have the inclination to 
 research GF(2^8) secret sharing schemes and write an implementation at the 
 present time, but if someone wants to take my BIP in that direction, then 
 okay.

I'm willing to fork it.
The maximum number of shares possible over GF(2^8) is 255.  That would
make M and x biases unnecessary.

--
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] Development Roadmap of Bitcoin Core 0.9.2

2014-04-22 Thread Wladimir
On Tue, Apr 22, 2014 at 3:30 PM, Warren Togami Jr. wtog...@gmail.com wrote:
 Development Roadmap of Bitcoin Core 0.9.2

 The Bitcoin Core developers have a desire to do a mostly bug-fix and
 translation update release in v0.9.2. A feature and string freeze will start
 about 3 weeks from now.

ACK, thanks for writing the announcement.

Wladimir

--
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] 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] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

2014-04-22 Thread Mark Friedenbach
Testnet vs mainnet is quite a separate issue than bitcoin vs altcoin.
Unfortunately few of the alts ever figured this out.

On 04/22/2014 01:39 AM, Tamas Blummer wrote:
 Extra encoding for testnet is quite useless complexity in face of many
 alt chains.
 BIPS should be chain agnostic.
 
 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


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

2014-04-22 Thread Tamas Blummer
Yes, it is current norm. I am questioning if we should hang on to it in BIPs.

I see testnet as a tool for a certain type of testing. Its existence is likely 
a consequence of Satoshi not writing unit tests and having automated 
integration tests, but creating a shadow chain to try things out, mostly 
manually.

I do not say testnet (as we know) would not be useful for certain tests. E.g. 
as we developed myTREZOR with slush it was useful to have a shared chain with 
worthless tokens and transactions we can both refer to. However for our 
automated tests chains-in-a-box are better as we can easily create and exactly 
re-create wierd situations on-the-fly.

While talking about BIP32 hierarchy use, several people argued to use a level 
of the hierarchy to identify the chain the key is used on. That level could 
identify testnet but as well an alt coin chain.

Above leads me thinking that testnet is far less important than to be addressed 
in every future BIP.

Regards,

Tamas Blummer
http://bitsofproof.com

On 22.04.2014, at 19:07, Jan Møller jan.mol...@gmail.com wrote:

 Treating testnet differently is quite the norm, we have that in BIP 32, 38, 
 70, SIPA private keys (no BIP for that I guess), bitcoin addresses etc. At 
 the same time none of them define values for alt coins as far as I recall.
 
 



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
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


[Bitcoin-development] Double-spending unconfirmed transactions is a lot easier than most people realise

2014-04-22 Thread Peter Todd
You may have seen my reddit post of the same title a few days ago:

http://www.reddit.com/r/Bitcoin/comments/239bj1/doublespending_unconfirmed_transactions_is_a_lot/

I've done some more experiments since, with good results. For instance
here's a real-world double-spend of the gambling service Lucky Bit:

Original: 7801c3b996716025dbac946ca7a123b7c1c5429341738e8a6286a389de51bd20

0100012a14c8e6ce1e625513847b2ff271b3e6a1849f2a634c601b7f383ef710483f796a4730440220692d09f5415f23118f865b81430990a15517954fd14a8bda74a5a38c4f2f39450220391f6251e39cdd3cab7363b912b897146a0a78e295f6ecd23b078c9f64ca7ae8012103a11c09c09874833eedc58a031d01d161ab4d2eba3874959537c5609ef5d5401f030c4d0f001976a914d5245b64fcf8e873a9d1c0bfe2d258492bec6cc888ac400d03001976a914da5dde8abec4f3b67561bcd06aaf28b790cff75588ac10271976a914c4c5d791fcb4654a1ef5e03fe0ad3d9c598f982788ac

Double-spend: f4e8e930bdfa3666b4a46c67544e356876a72ec70060130b2c7078c4ce88582a

0100012a14c8e6ce1e625513847b2ff271b3e6a1849f2a634c601b7f383ef710483f796a473044022074f0c6912b482c6b51f1a91fb2bdca3f3dde3a3aed4fc54bd5ed563390011c2d02202719fe49578591edfbdd4b79ceeaa7f9550e4323748b3dbdd4135f38e70c476d012103a11c09c09874833eedc58a031d01d161ab4d2eba3874959537c5609ef5d5401f01d9c90f001976a914d5245b64fcf8e873a9d1c0bfe2d258492bec6cc888ac

The double-spend was mined by Eligius and made use of the fact that
Eligius blacklists transactions to a number of addresses considered to
be spam by the pool operators; affected transactions are not added to
the Eligus mempool at all. Lucky Bit has a real-time display of bets as
they are accepted; I simply watched that display to determine whether or
not I had lost. With Eligius at 8% and the house edge at 1.75% the
attack is profitable when automated. My replace-by-fee patch(1) was
used, although as there are only a handful of such nodes running - none
connected directly to Eligius from what I can determine - I submitted
the double-spend transactions to Eligius directly via their pushtxn
webform.(2)

Of course, this is an especially difficult case, as you must send the
double-spend after the original transaction - normally just sending a
non-standard tx to Eligius first would suffice. Note how this defeats
Andresen's double-spend-relay patch(3) as proposed since the
double-spend is a non-standard transaction.

In discussion with Lucky Bit they have added case-specific code to
reject transactions with known blacklisted outputs; the above
double-spend I preformed is no longer possible. Of course, if the
(reused) Lucky Bit addresses are added to that blacklist, that approach
isn't viable - I suggest they switch to a scheme where addresses are not
reused. (per-customer? rotated?) They also have added code to keep track
of double-spend occurances and trigger human intervention prior to
unacceptable losses. Longer term as with most services (e.g. Just-Dice)
they intend to move to off-chain transactions. They are also considering
implementing replace-by-fee scorched earth(4) - in their case a single
pool, such as Eligius, implementing it would be enough to make the
attack unprofitable. It may also be enough security to allow users to
use their deposits prior to the first confirmation in a Just-Dice style
off-chain implementation.

1) https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.9.1

2) http://eligius.st/~wizkid057/newstats/pushtxn.php

3) https://github.com/bitcoin/bitcoin/pull/3354 and
   https://github.com/bitcoin/bitcoin/pull/3883

4) https://bitcointalk.org/index.php?topic=251233.msg2669189#msg2669189

-- 
'peter'[:-1]@petertodd.org
24abc60eebba42333d74b30635ca5fb0b7c776a579c307a8


signature.asc
Description: Digital signature
--
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] Economics of information propagation

2014-04-22 Thread Tom Harding
Jonathan -

These are a few things I've been wishing for recent data on:

  - 95th percentile transaction propagation time vs. fees/kb, vs. total fees
  - Count of blocks bypassing well-propagated transactions vs. fees/kb, 
vs. total fees
  - Signed-double-spend confirmation probability vs. broadcast time 
offset from first spend

On 4/20/2014 5:30 PM, Jonathan Levin wrote:
 at coinometrics we are working on a modified client to capture information on 
 network propagation and would invite any suggestions of any other useful 
 statistics that would be useful in the development of software.



--
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] Double-spending unconfirmed transactions is a lot easier than most people realise

2014-04-22 Thread Tom Harding

Since no complete solution to preventing 0-confirmation respends in the 
bitcoin network has been proposed, or is likely to exist, when 
evaluating partial solutions let's ask what kind of network does this 
move toward?

Does the solution move toward a network with simple rules, where the 
certainty that decreases from the many-confirmations state, down to 1 
confirmation, does not immediately disappear just below the time of 1 
confirmation?

A network where transaction submitters consider their (final) 
transactions to be unchangeable the moment they are transmitted, and 
where the network's goal is to confirm only transactions all of whose 
UTXO's have not yet been seen in a final transaction's input, has a 
chance to be such a network.  If respend attempts are broadcast widely, 
then after a time on the order of transaction propagation time ( 1 
minute) has passed, participants have a good chance to avoid relying on 
a transaction whose funds are spent to someone else.  This is both 
because after this time the network is unlikely to split on the primacy 
of one spend, and because the recipient, able to see a respend attempt, 
can withhold delivery of the good or service until confirmation.

Or, does the solution move toward a network that
  - Requires participants to have knowledge of the policies of multiple 
entities, like Eligius and whoever maintains the blacklist mentioned below?
  - Requires a transaction submitter to intently monitor transactions 
and try to climb over the top of attempted respends with 
scorched-earth triple spends, until a random moment some time between, 
let's say, 5 and 15 minutes in the future?
  - Punts the problem to off-network solutions?


On 4/22/2014 1:31 PM, Peter Todd wrote:
 You may have seen my reddit post of the same title a few days ago:

 http://www.reddit.com/r/Bitcoin/comments/239bj1/doublespending_unconfirmed_transactions_is_a_lot/

 I've done some more experiments since, with good results. For instance
 here's a real-world double-spend of the gambling service Lucky Bit:

 Original: 7801c3b996716025dbac946ca7a123b7c1c5429341738e8a6286a389de51bd20

 0100012a14c8e6ce1e625513847b2ff271b3e6a1849f2a634c601b7f383ef710483f796a4730440220692d09f5415f23118f865b81430990a15517954fd14a8bda74a5a38c4f2f39450220391f6251e39cdd3cab7363b912b897146a0a78e295f6ecd23b078c9f64ca7ae8012103a11c09c09874833eedc58a031d01d161ab4d2eba3874959537c5609ef5d5401f030c4d0f001976a914d5245b64fcf8e873a9d1c0bfe2d258492bec6cc888ac400d03001976a914da5dde8abec4f3b67561bcd06aaf28b790cff75588ac10271976a914c4c5d791fcb4654a1ef5e03fe0ad3d9c598f982788ac

 Double-spend: f4e8e930bdfa3666b4a46c67544e356876a72ec70060130b2c7078c4ce88582a

 0100012a14c8e6ce1e625513847b2ff271b3e6a1849f2a634c601b7f383ef710483f796a473044022074f0c6912b482c6b51f1a91fb2bdca3f3dde3a3aed4fc54bd5ed563390011c2d02202719fe49578591edfbdd4b79ceeaa7f9550e4323748b3dbdd4135f38e70c476d012103a11c09c09874833eedc58a031d01d161ab4d2eba3874959537c5609ef5d5401f01d9c90f001976a914d5245b64fcf8e873a9d1c0bfe2d258492bec6cc888ac

 The double-spend was mined by Eligius and made use of the fact that
 Eligius blacklists transactions to a number of addresses considered to
 be spam by the pool operators; affected transactions are not added to
 the Eligus mempool at all. Lucky Bit has a real-time display of bets as
 they are accepted; I simply watched that display to determine whether or
 not I had lost. With Eligius at 8% and the house edge at 1.75% the
 attack is profitable when automated. My replace-by-fee patch(1) was
 used, although as there are only a handful of such nodes running - none
 connected directly to Eligius from what I can determine - I submitted
 the double-spend transactions to Eligius directly via their pushtxn
 webform.(2)

 Of course, this is an especially difficult case, as you must send the
 double-spend after the original transaction - normally just sending a
 non-standard tx to Eligius first would suffice. Note how this defeats
 Andresen's double-spend-relay patch(3) as proposed since the
 double-spend is a non-standard transaction.

 In discussion with Lucky Bit they have added case-specific code to
 reject transactions with known blacklisted outputs; the above
 double-spend I preformed is no longer possible. Of course, if the
 (reused) Lucky Bit addresses are added to that blacklist, that approach
 isn't viable - I suggest they switch to a scheme where addresses are not
 reused. (per-customer? rotated?) They also have added code to keep track
 of double-spend occurances and trigger human intervention prior to
 unacceptable losses. Longer term as with most services (e.g. Just-Dice)
 they intend to move to off-chain transactions. They are also considering
 implementing replace-by-fee scorched earth(4) - in their case a single
 pool, such as Eligius, implementing it would be enough to make the
 attack unprofitable. It may also be enough security to 

Re: [Bitcoin-development] Double-spending unconfirmed transactions is a lot easier than most people realise

2014-04-22 Thread Matt Whitlock
On Tuesday, 22 April 2014, at 8:45 pm, Tom Harding wrote:
 A network where transaction submitters consider their (final) 
 transactions to be unchangeable the moment they are transmitted, and 
 where the network's goal is to confirm only transactions all of whose 
 UTXO's have not yet been seen in a final transaction's input, has a 
 chance to be such a network.

Respectfully, this is not the goal of miners. The goal of miners is to maximize 
profits. Always will be. If they can do that by enabling replace-by-fee (and 
they can), then they will. Altruism does not factor into business.

--
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