I too got this message and had to re-enable my membership on the list. There's
no reason why messages sent by the list to my address would be bouncing.
On Sunday, 21 June 2015, at 9:06 am, Braun Brelin wrote:
> Hi all,
>
> I got a message saying that my membership in the list was disabled due t
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 outd
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
ly
> define one rather than relying 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 wrote:
> >
> > On Friday, 19 June 20
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 defau
On Thursday, 18 June 2015, at 8:31 pm, Ross Nicoll wrote:
> I may disagree with Mike & Gavin on timescale, but I do believe there's
> a likelihood inaction will kill Bitcoin
An honest question: who is proposing inaction? I haven't seen anyone in this
whole, agonizing debate arguing that 1MB bloc
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 m
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 m
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 the limit" or "halve"
> > the limit? If you're going to use bits, I think you nee
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 transaction
Why should miners only be able to vote for "double the limit" or "halve" the
limit? If you're going to use bits, I think you need to use two bits:
0 0 = no preference ("wildcard" vote)
0 1 = vote for the limit to remain the same
1 0 = vote for the limit to be halved
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
tcoin Core. However, if another dev who is more familiar with the internals
would like to step forward, then that would be superior.
Respectfully submitted,
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
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 s
t of peers that is as diverse, and unpredictable as possible.
>
>
> On Mon, May 25, 2015 at 9:37 PM, Matt Whitlock
> 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 re
cal full 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, "
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
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 la
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,
On Friday, 8 May 2015, at 8:48 am, Matt Whitlock wrote:
> 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.
>
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
> fe
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, take
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 woul
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
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
nges
> to the single 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 under
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
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 bo
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 s
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 ap
To be more in the C++ spirit, I would suggest changing the (const
std::vector &sig, size_t &off) parameters to
(std::vector::const_iterator &itr, std::vector::const_iterator end).
Example:
bool ConsumeNumber(std::vector::const_iterator &itr,
std::vector::const_iterator end, unsigned int len)
{
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.
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
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
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 binar
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 integer)
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
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
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 Thursd
double spends on their own. (still limited of course to sybil
> attack concerns)
>
> Aaron Voisine
> breadwallet.com
>
>
> On Thu, Sep 25, 2014 at 7:07 PM, Matt Whitlock wrote:
> > What's to stop an attacker from broadcasting millions of spends of the same
> >
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
On Thursday, 31 July 2014, at 7:28 pm, Gregory Maxwell wrote:
> On Thu, Jul 31, 2014 at 6:38 PM, Matt Whitlock 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
> >
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 (reall
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
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.
On Tuesday, 17 June 2014, at 9:57 am, Wladimir wrote:
> Yes, as I said in the github topic
> (https://github.com/bitcoin/bitcoin/pull/4351) I suggest we adapt a
> string-based name space for extensions.
Why use textual strings? These fields are not for human consumption. Why not
use UUIDs, which
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
>
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 li
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
On Saturday, 14 June 2014, at 1:42 pm, Un Ix wrote:
> How about a prize for anyone who can spot any "malicious" strings within next
> hour?
I think it's more an issue of accidental breakage than any maliciousness. One
character in the wrong place in a language bundle somewhere can make the
diff
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 cau
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 Automat
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
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-- does>" like draft-maxwell-coinburning in the style of pre-WG IETF
> drafts.
Why is there such a high bar
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
On Tuesday, 22 April 2014, at 10:39 am, Jan Møller wrote:
> On Tue, Apr 22, 2014 at 10:29 AM, Matt Whitlock 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
> > >
On Tuesday, 22 April 2014, at 10:43 am, Tamas Blummer wrote:
> It is not about taste, but the fact that BIPs are used by many chains.
> Alts are useful for at least for experiments, and I think that the notion of
> main and testnet is superseeded by a wide choice of chains.
There aren't enough d
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 ju
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 hu
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
> > us
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 equiva
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 protec
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 []
encode16
Encod
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 ver
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 wo
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
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
'["03566474f987a012a69a0809725
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
t
On Monday, 7 April 2014, at 7:07 pm, Gregory Maxwell wrote:
> On Mon, Apr 7, 2014 at 6:46 PM, Matt Whitlock wrote:
> > On Monday, 7 April 2014, at 5:38 pm, Gregory Maxwell wrote:
> >> On Mon, Apr 7, 2014 at 5:33 PM, Nikita Schmidt
> >> wrote:
> >> &
On Monday, 7 April 2014, at 5:38 pm, Gregory Maxwell wrote:
> On Mon, Apr 7, 2014 at 5:33 PM, Nikita Schmidt
> 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.
> https://gitorious.org/bit
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
On Friday, 4 April 2014, at 10:51 am, Gregory Maxwell wrote:
> On Fri, Apr 4, 2014 at 10:16 AM, Matt Whitlock 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
>
On Friday, 4 April 2014, at 10:08 am, Gregory Maxwell wrote:
> On Fri, Apr 4, 2014 at 9:36 AM, Matt Whitlock 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&
On Friday, 4 April 2014, at 9:25 am, Gregory Maxwell wrote:
> On Fri, Apr 4, 2014 at 9:05 AM, Matt Whitlock 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
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 w
On Friday, 4 April 2014, at 5:51 pm, Nikita Schmidt wrote:
> On 4 April 2014 01:42, Matt Whitlock 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
> > gro
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 d
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 subsid
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
On Saturday, 29 March 2014, at 1:52 pm, Alan Reiner wrote:
> On 03/29/2014 01:19 PM, Matt Whitlock wrote:
> > I intentionally omitted the parameter M (minimum subset size) from the
> > shares because including it would give an adversary a vital piece of
> > information. Li
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 y
On Saturday, 29 March 2014, at 5:28 pm, Roy Badami wrote:
> Right now there are also people simply taking base58-encoded private
> keys and running them through -split.
>
> It has a lot going for it, since it can easily be reassembled on any
> Linux machine without special software (B Poetteri
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-bitcoi
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 wit
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 ma
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 it
On Saturday, 29 March 2014, at 7:36 am, Gregory Maxwell wrote:
> On Sat, Mar 29, 2014 at 7:28 AM, Watson Ladd 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 bitcoin, but I d
On Saturday, 29 March 2014, at 10:19 am, Jeff Garzik wrote:
> On Sat, Mar 29, 2014 at 10:10 AM, Matt Whitlock
> wrote:
> > Multisig does not allow for the topology I described. Say the board has
> > seven directors, meaning the majority threshold is four. This means the
>
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 rem
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
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
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 ma
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.
> > Ther
Abstract: A method is described for dividing a Bitcoin private key into shares
in a manner such that the key can be reconstituted from any sufficiently large
subset of the shares but such that individually the shares do not reveal any
information about the key. This method is commonly known as S
95 matches
Mail list logo
