On Wed, Mar 05, 2014 at 12:54:04PM -0800, Gregory Maxwell wrote:
On Wed, Mar 5, 2014 at 12:32 PM, Peter Todd p...@petertodd.org 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
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 then
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 you get
On Wed, Mar 12, 2014 at 12:02 PM, Mike Hearn m...@plan99.net 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
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 m...@plan99.net 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
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
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 st...@gk2.sk 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
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
On Mar 12, 2014, at 09:49 AM, Gary Rowe g.r...@froot.co.uk 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
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
On Wed, Mar 12, 2014 at 2:39 PM, Pavol Rusnak st...@gk2.sk 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
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 see.
On Wed, Mar 12, 2014 at 3:04 PM, Pavol Rusnak st...@gk2.sk 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
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
On Wed, Mar 12, 2014 at 3:24 PM, Pavol Rusnak st...@gk2.sk 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
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 st...@gk2.sk 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
On Mar 12, 2014, at 01:24 PM, Pavol Rusnak st...@gk2.sk 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
On Wed, Mar 12, 2014 at 4:08 PM, Jean-Paul Kogelman jeanpaulkogel...@me.com
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
21 matches
Mail list logo
