Re: [Bitcoin-development] Hard fork via miner vote

2015-06-20 Thread Matt Whitlock
On Saturday, 20 June 2015, at 8:11 pm, Pieter Wuille wrote: you want full nodes that have not noticed the fork to fail rather than see a slow but otherwise functional chain. Isn't that what the Alert mechanism is for? If these nodes continue running despite an alert telling them they're

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

2015-06-19 Thread Matt Whitlock
On Friday, 19 June 2015, at 9:18 am, Adrian Macneil wrote: If full-RBF sees any significant adoption by miners, then it will actively harm bitcoin adoption by reducing or removing the ability for online or POS merchants to accept bitcoin payments at all. Retail POS merchants probably should

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

2015-06-19 Thread Matt Whitlock
On Friday, 19 June 2015, at 3:53 pm, justusranv...@riseup.net wrote: I'd also like to note that prima facie doesn't mean always, it means that the default assumption, unless proven otherwise. Why would you automatically assume fraud by default? Shouldn't the null hypothesis be the default?

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

2015-06-19 Thread Matt Whitlock
on “prima facie” assumptions. Otherwise, I would recommend not relying on the existence of a signed transaction as proof of intent to pay… On Jun 19, 2015, at 9:36 AM, Matt Whitlock b...@mattwhitlock.name wrote: On Friday, 19 June 2015, at 3:53 pm, justusranv...@riseup.net wrote: I'd

Re: [Bitcoin-development] User vote in blocksize through fees

2015-06-12 Thread Matt Whitlock
On Friday, 12 June 2015, at 7:44 pm, Peter Todd wrote: On Fri, Jun 12, 2015 at 02:36:31PM -0400, Matt Whitlock wrote: On Friday, 12 June 2015, at 7:34 pm, Peter Todd wrote: On Fri, Jun 12, 2015 at 02:22:36PM -0400, Matt Whitlock wrote: Why should miners only be able to vote for double

Re: [Bitcoin-development] User vote in blocksize through fees

2015-06-12 Thread Matt Whitlock
On Friday, 12 June 2015, at 11:20 am, Mark Friedenbach wrote: Peter it's not clear to me that your described protocol is free of miner influence over the vote, by artificially generating transactions which they claim in their own blocks Miners could fill their blocks with garbage transactions

Re: [Bitcoin-development] Max Block Size: Simple Voting Procedure

2015-06-02 Thread Matt Whitlock
Why do it as an OP_RETURN output? It could be a simple token in the coinbase input script, similar to how support for P2SH was signaled among miners. And why should there be an explicit token for voting for the status quo? Simply omitting any indication should be an implicit vote for the status

Re: [Bitcoin-development] Cost savings by using replace-by-fee, 30-90%

2015-05-26 Thread Matt Whitlock
On Tuesday, 26 May 2015, at 11:22 am, Danny Thorpe wrote: What prevents RBF from being used for fraudulent payment reversals? Pay 1BTC to Alice for hard goods, then after you receive the goods broadcast a double spend of that transaction to pay Alice nothing? Your only cost is the higher

Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database

2015-05-25 Thread Matt Whitlock
On Monday, 25 May 2015, at 8:41 pm, Mike Hearn wrote: some wallets (e.g., Andreas Schildbach's wallet) don't even allow it - you can only spend confirmed UTXOs. I can't tell you how aggravating it is to have to tell a friend, Oh, oops, I can't pay you yet. I have to wait for the last

Re: [Bitcoin-development] Zero-Conf for Full Node Discovery

2015-05-25 Thread Matt Whitlock
On Tuesday, 26 May 2015, at 1:15 am, Peter Todd wrote: On Tue, May 26, 2015 at 12:52:07AM -0400, Matt Whitlock wrote: On Monday, 25 May 2015, at 11:48 pm, Jim Phillips wrote: Do any wallets actually do this yet? Not that I know of, but they do seed their address database via DNS, which

Re: [Bitcoin-development] Zero-Conf for Full Node Discovery

2015-05-25 Thread Matt Whitlock
, and unpredictable as possible. On Mon, May 25, 2015 at 9:37 PM, Matt Whitlock b...@mattwhitlock.name wrote: This is very simple to do. Just ping the all nodes address (ff02::1) and try connecting to TCP port 8333 of each node that responds. Shouldn't take but more than a few milliseconds

Re: [Bitcoin-development] Zero-Conf for Full Node Discovery

2015-05-25 Thread Matt Whitlock
This is very simple to do. Just ping the all nodes address (ff02::1) and try connecting to TCP port 8333 of each node that responds. Shouldn't take but more than a few milliseconds on any but the most densely populated LANs. On Monday, 25 May 2015, at 11:06 pm, Jim Phillips wrote: Is there

Re: [Bitcoin-development] Zero-Conf for Full Node Discovery

2015-05-25 Thread Matt Whitlock
node, which had connectivity to a single remote node over the Internet. Thus, all the lightweight wallets at the festival had Bitcoin network connectivity, but we only needed to backhaul the Bitcoin network's transaction traffic once. On May 25, 2015 11:37 PM, Matt Whitlock b

Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database

2015-05-09 Thread Matt Whitlock
Minimizing the number of UTXOs in a wallet is sometimes not in the best interests of the user. In fact, quite often I've wished for a configuration option like Try to maintain _[number]_ UTXOs in the wallet. This is because I often want to make multiple spends from my wallet within one block,

[Bitcoin-development] Proposed alternatives to the 20MB step function

2015-05-08 Thread Matt Whitlock
Between all the flames on this list, several ideas were raised that did not get much attention. I hereby resubmit these ideas for consideration and discussion. - Perhaps the hard block size limit should be a function of the actual block sizes over some trailing sampling period. For example,

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

2015-05-08 Thread Matt Whitlock
On Friday, 8 May 2015, at 3:32 pm, Joel Joonatan Kaartinen wrote: It seems you missed my suggestion about basing the maximum block size on the bitcoin days destroyed in transactions that are included in the block. I think it has potential for both scaling as well as keeping up a constant fee

Re: [Bitcoin-development] Block Size Increase

2015-05-06 Thread Matt Whitlock
I'm not so much opposed to a block size increase as I am opposed to a hard fork. My problem with a hard fork is that everyone and their brother wants to seize the opportunity of a hard fork to insert their own pet feature, and such a mad rush of lightly considered, obscure feature additions

Re: [Bitcoin-development] network disruption as a service and proof of local storage

2015-03-27 Thread Matt Whitlock
full node. Rob On 2015-03-26 23:04, Matt Whitlock wrote: Maybe I'm overlooking something, but I've been watching this thread with increasing skepticism at the complexity of the offered solution. I don't understand why it needs to be so complex. I'd like to offer an alternative

Re: [Bitcoin-development] network disruption as a service and proof of local storage

2015-03-27 Thread Matt Whitlock
On Friday, 27 March 2015, at 4:57 pm, Wladimir J. van der Laan wrote: On Fri, Mar 27, 2015 at 11:16:43AM -0400, Matt Whitlock wrote: I agree that someone could do this, but why is that a problem? Isn't the goal of this exercise to ensure more full nodes on the network? In order to be able

Re: [Bitcoin-development] network disruption as a service and proof of local storage

2015-03-27 Thread Matt Whitlock
On Friday, 27 March 2015, at 4:57 pm, Wladimir J. van der Laan wrote: On Fri, Mar 27, 2015 at 11:16:43AM -0400, Matt Whitlock wrote: I agree that someone could do this, but why is that a problem? Isn't the goal of this exercise to ensure more full nodes on the network? In order to be able

Re: [Bitcoin-development] network disruption as a service and proof of local storage

2015-03-26 Thread Matt Whitlock
Maybe I'm overlooking something, but I've been watching this thread with increasing skepticism at the complexity of the offered solution. I don't understand why it needs to be so complex. I'd like to offer an alternative for your consideration... Challenge: Send me: SHA256(SHA256(concatenation

Re: [Bitcoin-development] Address Expiration to Prevent Reuse

2015-03-25 Thread Matt Whitlock
On Tuesday, 24 March 2015, at 6:57 pm, Tom Harding wrote: It appears that a limited-lifetime address, such as the fanciful address = 4HB5ld0FzFVj8ALj6mfBsbifRoD4miY36v_349366 where 349366 is the last valid block for a transaction paying this address, could be made reuse-proof with bounded

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

2015-02-22 Thread Matt Whitlock
On Sunday, 22 February 2015, at 2:29 pm, Natanael wrote: In other words, you are unprotected and potentially at greater risk if you create a transaction depending on another zero-confirmation transaction. This happened to one of the merchants at the Bitcoin 2013 conference in San Jose. They

Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?

2015-01-28 Thread Matt Whitlock
On Wednesday, 28 January 2015, at 5:19 pm, Giuseppe Mazzotta wrote: On 28-01-15 16:42, Mike Hearn wrote: Just as a reminder, there is no obligation to use the OS root store. You can (and quite possibly should) take a snapshot of the Mozilla/Apple/MSFT etc stores and load it in your app. We

Re: [Bitcoin-development] [softfork proposal] Strict DER signatures

2015-01-21 Thread Matt Whitlock
To be more in the C++ spirit, I would suggest changing the (const std::vectorunsigned char sig, size_t off) parameters to (std::vectorunsigned char::const_iterator itr, std::vectorunsigned char::const_iterator end). Example: bool ConsumeNumber(std::vectorunsigned char::const_iterator itr,

Re: [Bitcoin-development] The legal risks of auto-updating wallet software; custodial relationships

2015-01-20 Thread Matt Whitlock
On Tuesday, 20 January 2015, at 12:40 pm, Peter Todd wrote: On Tue, Jan 20, 2015 at 12:23:14PM -0500, Matt Whitlock wrote: If you have the private keys for your users' bitcoins, then you are every bit as much the owner of those bitcoins as your users are. There is no custodial

Re: [Bitcoin-development] The legal risks of auto-updating wallet software; custodial relationships

2015-01-20 Thread Matt Whitlock
On Tuesday, 20 January 2015, at 10:46 am, Peter Todd wrote: I was talking to a lawyer with a background in finance law the other day and we came to a somewhat worrying conclusion: authors of Bitcoin wallet software probably have a custodial relationship with their users, especially if they use

Re: [Bitcoin-development] The legal risks of auto-updating wallet software; custodial relationships

2015-01-20 Thread Matt Whitlock
On Tuesday, 20 January 2015, at 6:44 pm, Tamas Blummer wrote: Knowing the private key and owning the linked coins is not necessarily the same in front of a court. At least in german law there is a difference between ‘Eigentum' means ownership and ‘Besitz’ means ability to deal with it.

Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?

2015-01-19 Thread Matt Whitlock
Even if a compact binary encoding is a high priority, there are more standard choices than Google Protocol Buffers. For example, ASN.1 is a very rigorously defined standard that has been around for decades, and ASN.1 even has an XML encoding (XER) that is directly convertible to/from the binary

Re: [Bitcoin-development] convention/standard for sorting public keys for p2sh multisig transactions

2015-01-14 Thread Matt Whitlock
On Wednesday, 14 January 2015, at 3:53 pm, Eric Lombrozo wrote: Internally, pubkeys are DER-encoded integers. I thought pubkeys were represented as raw integers (i.e., they're embedded in Script as a push operation whose payload is the raw bytes of the big-endian representation of the

Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time

2014-10-03 Thread Matt Whitlock
Is there a reason why we can't have the new opcode simply replace the top stack item with the block height of the txout being redeemed? Then arbitrary logic could be implemented, including output cannot be spent until a certain time and also output can ONLY be spent until a certain time, as

Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time

2014-10-03 Thread Matt Whitlock
Oops, sorry. I meant: replace the top stack item with the block height of the txin doing the redeeming. (So the script can calculate the current time to some reference time embedded in the script.) On Friday, 3 October 2014, at 10:28 am, Matt Whitlock wrote: Is there a reason why we can't

Re: [Bitcoin-development] SPV clients and relaying double spends

2014-09-25 Thread Matt Whitlock
limited of course to sybil attack concerns) Aaron Voisine breadwallet.com On Thu, Sep 25, 2014 at 7:07 PM, Matt Whitlock b...@mattwhitlock.name wrote: What's to stop an attacker from broadcasting millions of spends of the same output(s) and overwhelming nodes with slower connections

Re: [Bitcoin-development] SPV clients and relaying double spends

2014-09-25 Thread Matt Whitlock
What's to stop an attacker from broadcasting millions of spends of the same output(s) and overwhelming nodes with slower connections? Might it be a better strategy not to relay the actual transactions (after the first) but rather only propagate (once) some kind of double-spend alert? On

Re: [Bitcoin-development] Does anyone have anything at all signed by Satoshi's PGP key?

2014-09-15 Thread Matt Whitlock
On Monday, 15 September 2014, at 5:10 pm, Thomas Zander wrote: So for instance I start including a bitcoin public key in my email signature. I don't sign the emails or anything like that, just to establish that everyone has my public key many times in their email archives. Then when I need

Re: [Bitcoin-development] deterministic transaction expiration

2014-07-31 Thread Matt Whitlock
It would make more sense to introduce a new script opcode that pushes the current block height onto the operand stack. Then you could implement arbitrary logic about which blocks the transaction can be valid in. This would require that the client revalidate all transactions in its mempool

Re: [Bitcoin-development] deterministic transaction expiration

2014-07-31 Thread Matt Whitlock
On Thursday, 31 July 2014, at 7:28 pm, Gregory Maxwell wrote: On Thu, Jul 31, 2014 at 6:38 PM, Matt Whitlock b...@mattwhitlock.name wrote: It would make more sense to introduce a new script opcode that pushes the current block height onto the operand stack. Then you could implement

Re: [Bitcoin-development] Self-dependency transaction question...

2014-07-14 Thread Matt Whitlock
On Sunday, 13 July 2014, at 7:32 pm, Richard Moore wrote: P.S. If it is valid, another question; what would happen if a transaction was self-referencing? I realize it would be very difficult to find one, but if I could find a transaction X whose input was X and had an output Y, would Y be a

Re: [Bitcoin-development] Bitcoin Protocol Specification

2014-07-08 Thread Matt Whitlock
Is anyone working on a similar specification document for Satoshi's P2P protocol? I know how blocks and transactions are structured and verified, but I'm interested in knowing how they're communicated over the network.

Re: [Bitcoin-development] Incentivizing the running of full nodes

2014-06-16 Thread Matt Whitlock
How can there be any kind of lottery that doesn't involve proof of work or proof of stake? Without some resource-limiting factor, there is no way to limit the number of lottery tickets any given individual could acquire. The very process of Bitcoin mining was invented specifically to overcome

Re: [Bitcoin-development] Incentivizing the running of full nodes

2014-06-16 Thread Matt Whitlock
On Monday, 16 June 2014, at 5:07 pm, Justus Ranvier wrote: On 06/16/2014 04:25 PM, Matt Whitlock wrote: How can there be any kind of lottery that doesn't involve proof of work or proof of stake? Without some resource-limiting factor, there is no way to limit the number of lottery tickets

Re: [Bitcoin-development] Incentivizing the running of full nodes

2014-06-16 Thread Matt Whitlock
On Monday, 16 June 2014, at 7:59 pm, Mike Hearn wrote: This is a cool idea, but doesn't it generate some perverse incentives? If I'm running a full node and I want to pay CheapAir for some plane tickets, I'll want to pay in the greatest number of individual transactions possible Peers

Re: [Bitcoin-development] Going to tag 0.9.2 final

2014-06-13 Thread Matt Whitlock
On Friday, 13 June 2014, at 9:24 pm, xor wrote: On Friday, June 13, 2014 12:18:37 PM Wladimir wrote: If I do not hear anything, I will do a last-minute language import High risk projects as Bitcoin should NOT see ANY changes between release candidates and releases. You can cause severe

Re: [Bitcoin-development] Paper Currency

2014-05-17 Thread Matt Whitlock
On Saturday, 17 May 2014, at 11:31 am, Jerry Felix wrote: I picked some BIP numbers myself that seem to be available. I'm quite certain you're explicitly *NOT* supposed to do this. -- Accelerate Dev Cycles with

Re: [Bitcoin-development] DNS seeds unstable

2014-05-16 Thread Matt Whitlock
Is Peter Todd's server actually up? The Google public DNS resolver at 8.8.8.8 can't resolve testnet-seed.bitcoin.petertodd.org either (SERVFAIL). On Friday, 16 May 2014, at 6:34 pm, Andreas Schildbach wrote: Apparently British Telecom also cannot speak to Peter Todd's server. That another

Re: [Bitcoin-development] Prenumbered BIP naming

2014-05-12 Thread Matt Whitlock
On Monday, 12 May 2014, at 9:53 am, Gregory Maxwell wrote: I've noticed some folks struggling to attach labels to their yet to be numbered BIPs. I'd recommend people call them draft-main author name-what it does like draft-maxwell-coinburning in the style of pre-WG IETF drafts. Why is

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

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

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

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

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

[Bitcoin-development] Bug in 2-of-3 transaction signing in Bitcoind?

2014-04-15 Thread Matt Whitlock
For the life of me, I cannot figure out what's wrong with this. It seems like Bitcoind has lost its mind. I'm trying to redeem a 2-of-3 multisig P2SH output using a raw transaction. Here's the address that the P2SH output was sent to: $ bitcoind createmultisig 2

Re: [Bitcoin-development] Bug in 2-of-3 transaction signing in Bitcoind?

2014-04-15 Thread Matt Whitlock
Thanks for the quick reply to both of you, Mike and Pieter. I feel foolish for posting to this list, because the debug.log does indeed say inputs already spent. That's so weird, though, because we haven't been able to get anything to accept the transaction, seemingly, and yet it was accepted

Re: [Bitcoin-development] Bug in 2-of-3 transaction signing in Bitcoind?

2014-04-15 Thread Matt Whitlock
On Tuesday, 15 April 2014, at 5:30 pm, Mike Hearn wrote: That's so weird, though, because we haven't been able to get anything to accept the transaction, seemingly, and yet it was accepted into the block chain 15 blocks ago. If the tx is already in the block chain then it won't be

Re: [Bitcoin-development] Bug in 2-of-3 transaction signing in Bitcoind?

2014-04-15 Thread Matt Whitlock
On Tuesday, 15 April 2014, at 8:47 am, Mike Belshe wrote: For what it is worth, I found btcd (the go implementation of bitcoind) has much better error/diagnostics messages. It would have given you more than -22 TX Rejected. I used it to debug my own multi-sig transactions and it was very

Re: [Bitcoin-development] Bug in 2-of-3 transaction signing in Bitcoind?

2014-04-15 Thread Matt Whitlock
On Tuesday, 15 April 2014, at 6:39 pm, Chris Beams wrote: Looks interesting. Is the source available? The intent is to open-source it. We will do so when I'm confident that we have all the kinks worked out. Here's what it can do presently: $ ./btctool usage: ./btctool function [args]

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

2014-04-08 Thread Matt Whitlock
On Monday, 7 April 2014, at 7:07 pm, Gregory Maxwell wrote: On Mon, Apr 7, 2014 at 6:46 PM, Matt Whitlock b...@mattwhitlock.name wrote: On Monday, 7 April 2014, at 5:38 pm, Gregory Maxwell wrote: On Mon, Apr 7, 2014 at 5:33 PM, Nikita Schmidt nik...@megiontechnologies.com wrote

Re: [Bitcoin-development] have there been complains about network congestion? (router crashes, slow internet when running Bitcoin nodes)

2014-04-08 Thread Matt Whitlock
On Tuesday, 8 April 2014, at 12:13 pm, Angel Leon wrote: I was wondering if we have or expect to have these issues in the future, perhaps uTP could help greatly the performance of the entire network at some point. Or people could simply learn to configure their routers correctly. The only

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

2014-04-07 Thread Matt Whitlock
On Monday, 7 April 2014, at 5:38 pm, Gregory Maxwell wrote: On Mon, Apr 7, 2014 at 5:33 PM, Nikita Schmidt nik...@megiontechnologies.com wrote: Regarding the choice of fields, any implementation of this BIP will need big integer arithmetic to do base-58 anyway. Nah, it doesn't. E.g.

Re: [Bitcoin-development] Finite monetary supply for Bitcoin

2014-04-05 Thread Matt Whitlock
On Saturday, 5 April 2014, at 12:21 pm, Jorge Timón wrote: I like both DD-MM- and -MM-DD. I just dislike MM-DD- and -DD-MM. Your preferences reflect a cultural bias. The only entirely numeric date format that is unambiguous across all cultures is -MM-DD. (No culture uses

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

2014-04-04 Thread Matt Whitlock
On Friday, 4 April 2014, at 5:51 pm, Nikita Schmidt wrote: On 4 April 2014 01:42, Matt Whitlock b...@mattwhitlock.name wrote: The fingerprint field, Hash16(K), is presently specified as a 16-bit field. Rationale: There is no need to consume 4 bytes just to allow shares to be grouped

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

2014-04-04 Thread Matt Whitlock
On Friday, 4 April 2014, at 7:14 am, Gregory Maxwell wrote: I still repeat my concern that any private key secret sharing scheme really ought to be compatible with threshold ECDSA, otherwise we're just going to have another redundant specification. I have that concern too, but then how can we

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

2014-04-04 Thread Matt Whitlock
On Friday, 4 April 2014, at 9:25 am, Gregory Maxwell wrote: On Fri, Apr 4, 2014 at 9:05 AM, Matt Whitlock b...@mattwhitlock.name wrote: On Friday, 4 April 2014, at 7:14 am, Gregory Maxwell wrote: I still repeat my concern that any private key secret sharing scheme really ought

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

2014-04-04 Thread Matt Whitlock
On Friday, 4 April 2014, at 10:08 am, Gregory Maxwell wrote: On Fri, Apr 4, 2014 at 9:36 AM, Matt Whitlock b...@mattwhitlock.name wrote: Are you proposing to switch from prime fields to a binary field? Because if you're going to break up a secret into little pieces, you can't assume

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

2014-04-04 Thread Matt Whitlock
On Friday, 4 April 2014, at 10:51 am, Gregory Maxwell wrote: On Fri, Apr 4, 2014 at 10:16 AM, Matt Whitlock b...@mattwhitlock.name wrote: Honestly, that sounds a lot more complicated than what I have now. I made my current implementation because I just wanted something simple that would

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

2014-04-03 Thread Matt Whitlock
On Thursday, 3 April 2014, at 4:41 pm, Nikita Schmidt wrote: I agree with the recently mentioned suggestion to make non-essential metadata, namely key fingerprint and degree (M), optional. Their 4-byte and 1-byte fields can be added individually at an implementation's discretion. During

Re: [Bitcoin-development] Finite monetary supply for Bitcoin

2014-04-01 Thread Matt Whitlock
The creation date in your BIP header has the wrong format. It should be 01-04-2014, per BIP 1. :-) On Tuesday, 1 April 2014, at 9:00 pm, Pieter Wuille wrote: Hi all, I understand this is a controversial proposal, but bear with me please. I believe we cannot accept the current subsidy

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

2014-03-29 Thread Matt Whitlock
On Saturday, 29 March 2014, at 4:51 am, Matt Whitlock wrote: On Saturday, 29 March 2014, at 9:44 am, Tamas Blummer wrote: I used Shamir's Secret Sharing to decompose a seed for a BIP32 master key, that is I think more future relevant than a single key. Therefore suggest to adapt the BIP

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

2014-03-29 Thread Matt Whitlock
On Saturday, 29 March 2014, at 9:44 am, Tamas Blummer wrote: I used Shamir's Secret Sharing to decompose a seed for a BIP32 master key, that is I think more future relevant than a single key. Therefore suggest to adapt the BIP for a length used there typically 16 or 32 bytes and have a magic

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

2014-03-29 Thread Matt Whitlock
On Saturday, 29 March 2014, at 10:08 am, Chris Beams wrote: Matt, could you expand on use cases for which you see Shamir's Secret Sharing Scheme as the best tool for the job? In particular, when do you see that it would be superior to simply going with multisig in the first place? Perhaps

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

2014-03-29 Thread Matt Whitlock
On Saturday, 29 March 2014, at 10:08 am, Chris Beams wrote: Matt, could you expand on use cases for which you see Shamir's Secret Sharing Scheme as the best tool for the job? In particular, when do you see that it would be superior to simply going with multisig in the first place? Perhaps

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

2014-03-29 Thread Matt Whitlock
On Saturday, 29 March 2014, at 2:36 pm, Mike Hearn wrote: Right - the explanation in the BIP about the board of directors is IMO a little misleading. The problem is with splitting a private key is that at some point, *someone* has to get the full private key back and they can then just

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

2014-03-29 Thread Matt Whitlock
On Saturday, 29 March 2014, at 10:19 am, Jeff Garzik wrote: On Sat, Mar 29, 2014 at 10:10 AM, Matt Whitlock b...@mattwhitlock.name wrote: Multisig does not allow for the topology I described. Say the board has seven directors, meaning the majority threshold is four. This means

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

2014-03-29 Thread Matt Whitlock
On Saturday, 29 March 2014, at 7:36 am, Gregory Maxwell wrote: On Sat, Mar 29, 2014 at 7:28 AM, Watson Ladd w...@uchicago.edu wrote: This is not the case: one can use MPC techniques to compute a signature from shares without reconstructing the private key. There is a paper on this for

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

2014-03-29 Thread Matt Whitlock
On Saturday, 29 March 2014, at 11:08 am, Watson Ladd wrote: https://freedom-to-tinker.com/blog/stevenag/new-research-better-wallet-security-for-bitcoin/ Thanks. This is great, although it makes some critical references to an ACM paper for which no URL is provided, and thus I cannot implement

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

2014-03-29 Thread Matt Whitlock
On Saturday, 29 March 2014, at 9:44 am, Tamas Blummer wrote: I used Shamir's Secret Sharing to decompose a seed for a BIP32 master key, that is I think more future relevant than a single key. Therefore suggest to adapt the BIP for a length used there typically 16 or 32 bytes and have a magic

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

2014-03-29 Thread Matt Whitlock
On Saturday, 29 March 2014, at 12:59 pm, Alan Reiner wrote: I won't lie, there's a lot of work that goes into making an interface that makes this feature usable. The user needs clear ways to identify which fragments are associated with which wallet, and which fragments are compatible with

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

2014-03-29 Thread Matt Whitlock
On Saturday, 29 March 2014, at 10:25 am, Dev Random wrote: On Sat, 2014-03-29 at 11:44 -0400, Matt Whitlock wrote: On Saturday, 29 March 2014, at 11:08 am, Watson Ladd wrote: https://freedom-to-tinker.com/blog/stevenag/new-research-better-wallet-security-for-bitcoin/ Thanks

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

2014-03-29 Thread Matt Whitlock
On Saturday, 29 March 2014, at 10:48 am, devrandom wrote: On Sat, 2014-03-29 at 13:38 -0400, Matt Whitlock wrote: Threshold ECDSA certainly sounds nice, but is anyone working on a BIP for it? I would take it on myself, but I don't understand it well enough yet, and publicly available

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

2014-03-29 Thread Matt Whitlock
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.