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 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:
- 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
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
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
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
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
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
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
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
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
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
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,
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
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,
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,
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
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.
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
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
20 matches
Mail list logo
