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