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
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 Tue, Apr 22, 2014 at 1: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.
I haven't seen commentary from you on the Kogelman draft, it would be
helpful there: https://bitcointalk.org/index.
>
>
> > - 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.
>
>
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 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 o
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 wrote:
> On Tuesday, 22 April 2014, at 4:11 am, Matt Whitlock wrote:
>> On Tuesday, 22 April 2
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 wrote:
> On Tuesday, 22 April 2014, at 10:27 am, Jan Møller wrote:
> > > >
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
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 wrote:
> 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
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 wit
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
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.
Regards,
Tamas Blummer
http://bitsofproof.com
signature.asc
Description: Message sig
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
The development of BitID has had some progress, and we have now a working
wallet prototype based on Android Bitcoin Wallet (bitoinj).
The user flow is quite nice and if you are curious here is a short video
demonstration :
https://www.youtube.com/watch?v=3eepEWTnRTc
By default, each new first auth
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, 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
> > > > > allow
> > > > > the user to sel
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
th
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.
The purpose of this development roadmap is to communicate the project
intent and to b
>
> 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
On Tue, Apr 22, 2014 at 3:30 PM, Warren Togami Jr. 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 w
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. I
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.
>
> Regar
I use several test chains while testing my software, the official test net, a
standalone net in house and even chains only created on the fly for unit tests.
I found no use of distinguishing serialization of keys while using any of them.
If you have some deep insights about why this is needed sh
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.
On Tue, Apr 22, 2014 at 5:49 PM, Tamas Blummer wrote:
> I use several
What I was saying is that while it may or may not make sense to have
separate prefixes for testnet, it makes no sense to have per-alt prefixes.
On 04/22/2014 08:49 AM, Tamas Blummer wrote:
> I use several test chains while testing my software, the official test
> net, a standalone net in house and
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, most
On Tue, Apr 22, 2014 at 11:29 AM, Tamas Blummer wrote:
> 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
> integ
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 Luck
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. broadca
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
cert
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
A lot of these "should the network..." questions depend on business
rules and business models.
Even if a 0-conf double spend is possible in a given business
situation, the incentives quite often are aligned to avoid
double-spend attempts in any case. Any physical good being shipped
can "accept" t
>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-s
That piece of horse equipment is called a bit in the US too. But the point
stands: most people don't use "bit" on a daily basis other than referring to
"a little bit of ."
-Original Message-
From: Wladimir [mailto:laa...@gmail.com]
Sent: Sunday, April 20, 2014 11:27 AM
To: Chris Pacia
Cc
So you agree, that SSS should not contain specific flag for testnet?
Or for that matter not even BIP32 needs them since it is not an address to send
to.
Regards,
Tamas Blummer
http://bitsofproof.com
On 22.04.2014, at 20:46, Gregory Maxwell wrote:
> Testnet is not normally addressed in BIPs at
On Tue, Apr 22, 2014 at 10:33 PM, Tamas Blummer wrote:
> So you agree, that SSS should not contain specific flag for testnet?
>
> Or for that matter not even BIP32 needs them since it is not an address to
> send to.
I think the convention we have so far is that addresses and address
relate thing
On 04/22/2014 09:29 PM, Jan Møller wrote:
>>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
38 matches
Mail list logo
