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
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 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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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 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.
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
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
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
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
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
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
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]
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
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
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
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
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
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 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
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
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 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
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
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 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
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
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
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
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
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
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
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
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
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
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.
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,
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
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
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
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
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
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
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
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
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,
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
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 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
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
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
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?
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
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
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
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
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
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
, 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
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
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
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
76 matches
Mail list logo
