On Wed, Mar 05, 2014 at 12:54:04PM -0800, Gregory Maxwell wrote:
> On Wed, Mar 5, 2014 at 12:32 PM, Peter Todd wrote:
> > That's nice, but I wrote my advice to show people how even if they don't
> > know any crypto beyond what the "black boxes" do - the absolute minimum
> > you need to know to wri
Good to see so much activity! But please do remember, there's more to
"multisig" than just keys - you need the whole user experience to be
planned out and specced for fully interoperable implementations.
For the "group account for an organisation" feature, you don't really
want to expose end u
On 03/12/2014 04:17 AM, Jean-Paul Kogelman wrote:
> We've been hard at work updating the spec to include features that were
> requested. We've removed the Scrypt dependency that was present in the
> initial drafts, added new KDFs, added plausible deniability and have a
> reference implementation
On Wed, Mar 12, 2014 at 5:48 AM, Mike Hearn wrote:
> CoinVault is also using a partially signed transaction format whereby
> 0-length placeholders are used for missing signatures in the transaction
> scripts.
>
> I don't know how you are implementing this/what framework you're using, but
> I sugge
On Mar 12, 2014, at 6:11 AM, Pavol Rusnak wrote:
> On 03/12/2014 04:17 AM, Jean-Paul Kogelman wrote:
>> We've been hard at work updating the spec to include features that were
>> requested. We've removed the Scrypt dependency that was present in the
>> initial drafts, added new KDFs, added pla
On 03/12/2014 04:45 PM, Jean-Paul Kogelman wrote:
> Yes I am. There are some differences between BIP 39 and my proposal though.
>
> - BIP 39 offers an easy list of words, no gnarly string of case sensitive
> letters and numbers.
Which is better IMO. I can't imagine anyone writing down a long Ba
>
> This is what bitcoind produces and expects by default, for a partially
> signed transaction.
What happens if the act of filling out the signature pushes the transaction
into a higher fee level?
--
Learn Graph Database
On 12 March 2014 16:02, Mike Hearn wrote:
> This is what bitcoind produces and expects by default, for a partially
>> signed transaction.
>
>
> What happens if the act of filling out the signature pushes the
> transaction into a higher fee level?
>
Can this be calculated in advance knowing the i
>
> Can this be calculated in advance knowing the initial transaction size and
> the number of signatures required?
>
Sure of course. You assume each signature to be placed in the tx is 73
bytes. Not very hard, but if the tx you get back from the API doesn't
contain such a 73-byte sentinel value t
On Wed, Mar 12, 2014 at 05:14:25PM +0100, Mike Hearn wrote:
> >
> > Can this be calculated in advance knowing the initial transaction size and
> > the number of signatures required?
> >
>
> Sure of course. You assume each signature to be placed in the tx is 73
> bytes. Not very hard, but if the tx
On Wed, Mar 12, 2014 at 12:02 PM, Mike Hearn wrote:
>> This is what bitcoind produces and expects by default, for a partially
>> signed transaction.
> What happens if the act of filling out the signature pushes the transaction
> into a higher fee level?
Partially signed and multisig transactions
>
> Partially signed and multisig transactions within bitcoind go through
> the raw transaction API, which does absolutely nothing if the sig
> pushes the TX to a higher fee level.
Well, we'll have to make sure this is carefully and loudly documented in
the new developer part of the website that'
On Wed, Mar 12, 2014 at 05:41:33PM +0100, Mike Hearn wrote:
> >
> > Partially signed and multisig transactions within bitcoind go through
> > the raw transaction API, which does absolutely nothing if the sig
> > pushes the TX to a higher fee level.
>
>
> Well, we'll have to make sure this is care
Jean-Paul, it may be worth noting that the BIP39 word list is integrated
into Bitcoinj so will likely become the de facto standard for Android,
Trezor web and several desktop wallets. Anyone deviating from that word
list would likely find themselves in an isolated pocket.
Regarding the timestamp,
On Wed, Mar 12, 2014 at 12:41 PM, Mike Hearn wrote:
>> Partially signed and multisig transactions within bitcoind go through
>> the raw transaction API, which does absolutely nothing if the sig
>> pushes the TX to a higher fee level.
>
>
> Well, we'll have to make sure this is carefully and loudly
For a p2sh multisig transaction, the serialized script looks like this:
m [pubkey] ... [pubkey] n OP_CHECKMULTISIG
The p2sh address is the hash of this script. The public keys can come in
any order, but the hash depends on the order. If you have a list of
public keys, to which address do you send
This spec offers a lot of benefits over BIP 0038:
* Multiple KDFs (I think the chosen list is reasonable and fits all
required use cases)
* Multiple seed lengths
* Explicit BIP 0032 support
* Creation date field
* Plausible deniability (via the multiple-password mechanism)
I don't think it makes
On Mar 12, 2014, at 08:55 AM, Pavol Rusnak wrote:On 03/12/2014 04:45 PM, Jean-Paul Kogelman wrote:Yes I am. There are some differences between BIP 39 and my proposal though.- BIP 39 offers an easy list of words, no gnarly string of case sensitive letters and numbers. Which is better IMO. I can't i
Most of the issue seems to be because of
CWalletDB::ReorderTransactions. After applying zapwallettxes, I
noticed that listtransactions was no longer listing new transactions.
After further investigation, new tx records were being given a low
nOrderPos number while old acentry records were high enou
On Mar 12, 2014, at 09:49 AM, Gary Rowe wrote:Jean-Paul, it may be worth noting that the BIP39 word list is integrated into Bitcoinj so will likely become the de facto standard for Android, Trezor web and several desktop wallets. Anyone deviating from that word list would likely find themselves in
This is purely a MultiBit HD thing. Nothing to do with the BIP, unless the
wider community felt that it would be generally useful.
It has nothing to do with internal word list checking and is purely an
additional check to reduce the blockchain search load for SPV clients when
restoring wallets.
Hi Ryan,
Probably the most neutral way to go about this is to lexicographically
sort by encoded representation bytes. In java, that would be
ECPoint.getEncoded.
This is what we currently do in our watchdog Oracle.
On Wed, 2014-03-12 at 13:10 -0400, Ryan X. Charles wrote:
> For a p2sh multisig t
On 03/12/2014 08:26 PM, Jean-Paul Kogelman wrote:
> So upon entering a password with a typo, the user will not be notified of an
> error, but be presented with a wallet balance of 0, after the blockchain has
> been scanned. I'm sorry, but that's not the kind of experience I would want
> to
> pr
On Wed, Mar 12, 2014 at 2:39 PM, Pavol Rusnak wrote:
> On 03/12/2014 08:26 PM, Jean-Paul Kogelman wrote:
> > So upon entering a password with a typo, the user will not be notified
> of an
> > error, but be presented with a wallet balance of 0, after the blockchain
> has
> > been scanned. I'm sorr
On 03/12/2014 08:55 PM, William Yager wrote:
> The proposed BIP uses a bloom filter, so it has both plausible deniability
> *and
> *typo checking. The bloom filter is optimized for two elements and will
> catch something like 99.9975% of typos, despite allowing two different
> passwords.
Ok, I se
On Wed, Mar 12, 2014 at 3:04 PM, Pavol Rusnak wrote:
> On 03/12/2014 08:55 PM, William Yager wrote:
> > The proposed BIP uses a bloom filter, so it has both plausible
> deniability *and
> > *typo checking. The bloom filter is optimized for two elements and will
> > catch something like 99.9975% o
On 03/12/2014 09:10 PM, William Yager wrote:
> implement this is to allow semi-trusted devices (like desktop PCs) to do
> all the "heavy lifting". The way the spec is defined, it is easy to have a
> more powerful device do all the tough key stretching work without
> significantly compromising the s
On Wed, Mar 12, 2014 at 3:24 PM, Pavol Rusnak wrote:
> On 03/12/2014 09:10 PM, William Yager wrote:
> > implement this is to allow semi-trusted devices (like desktop PCs) to do
> > all the "heavy lifting". The way the spec is defined, it is easy to have
> a
> > more powerful device do all the tou
On 03/12/2014 09:37 PM, William Yager wrote:
> (that group of people includes me), PBKDF2-HMAC-SHA512 is very easy to
> implement even on devices that only have a few kB of RAM, and even though
> our number of rounds is very aggressive (2^16 and 2^21), it will still run
> in reasonable time even on
On Wed, Mar 12, 2014 at 3:42 PM, Pavol Rusnak wrote:
> On 03/12/2014 09:37 PM, William Yager wrote:
> > (that group of people includes me), PBKDF2-HMAC-SHA512 is very easy to
> > implement even on devices that only have a few kB of RAM, and even though
> > our number of rounds is very aggressive
On Mar 12, 2014, at 01:24 PM, Pavol Rusnak wrote:On 03/12/2014 09:10 PM, William Yager wrote:implement this is to allow semi-trusted devices (like desktop PCs) to doall the "heavy lifting". The way the spec is defined, it is easy to have amore powerful device do all the tough key stretching work w
On Wed, Mar 12, 2014 at 4:08 PM, Jean-Paul Kogelman wrote:
>
> Agreed, this is a valid concern. This could possibly allow a 3rd party to
> crack the password, but then again, they would not gain access to any key
> material. So yes, you could expose your password, but your key would still
> be sa
32 matches
Mail list logo
