> as it seems bad design to have to fix and maintain a wordlist for every
language as the checksum depends on it.
>From BIP39:
> The conversion of the mnemonic sentence to a binary seed is completely
independent from generating the sentence. This results in rather simple
code; there are no const
Nope.
This is how Electrum treats BIP39 restoring as well, try it out.
-Jon
2018年11月16日(金) 23:04、Neill Miller さん（nei...@thecodefactory.org）のメッセージ:
> On Fri, Nov 09, 2018 at 02:17:30PM +0900, Jonathan Underwood via
> bitcoin-dev wrote:
> > If more apps would implement to the word
Hello all,
Just wanted to pick your brains about an idea for PSBT extension.
One problem we try to solve with cold -> warm and warm -> hot sends for our
exchange wallet is "How do I know that the address I am sending to is not a
hacker's address that was swapped in between unsigned tx creation an
dently described in its own documentation,
> that would include the particulars of the format for the
> metainformation. This would also make it easier to implement PSBT for
> simple cases, because the 'core specification' would not grow that big.
>
> [1]
>
> https://lis
> better dealt with outside of PSBT, as 'PSBT metainformation', or
> > > using some form of 'vendor-specific', or 'metainformation-specific'
> > > PSBT field. This way each usecase can be independently described in
> > > its own documentation, t
to prevent this [1] is to sign the whole 'xpub package'
>> > > > > of the multisig wallet, but there is also an issue of 'partial
>> > > > > compromize', where some of the keys in a multisig warm wallet is
>> > > > > compromized, and you do no
not want to regard a particular 'xpub
> > > > > package' as trusted. My idea was [2] to use an auxiliary message
> > > > > that would be signed along with the 'xpub package', and that
> > > > > message can include specific 'epoch&#x
compromized, attackers can then create a single-sig
> > > > > > > destination address that they control, and move the coins
> > > > > > > in a chain of two transactions, first to this single-sig
> > > > > > > address, and then
Hi Peter,
tl;dr The problem this solves is "How can a signer verify an address with
HD changing the address every time?"
As an aside: (This is sort of explaining the current PR for the 0x01 global
field (separate from mine))
The problem is more easily understood with change addresses: If someone
Thanks for the reply Peter. Comments inline:
2019年6月28日(金) 23:37 Peter D. Gray :
> Thanks I get the idea better now: You want the PSBT creator to be
> able to indicate to the signers that it (the PSBT creator) controls
> specific outputs that don't otherwise look like change.
>
> Some problems:
>
gt; > > > trusted.
> > > > > > >
> > > > > > > I seems to me that if you sign individual xpubs of a
> > > > > > > multisig warm wallet, and one key from that multisig is
> > > > > > > compromized, attackers can then create a single-sig
> > &g
Even if the difference is apparent outside the signed data (in the output).
Signing the data explicitly is more secure.
ie. if some sort of vulnerability / way to break this system for 1-of-1
multisig is found, someone who signed a single sig xpub whitelist will not
be exposed.
2019年6月29日(土) 13:4
Hi all,
Just to be brief, I'll kick off with an attack scenario.
1. I am a signer, I get a PSBT that is ready to sign. I parse. I sign
according to the PSBT as-is.
2. I notice my UTXO was stolen by a hacker because they changed my PSBT
input's sighashtype to SIGHASH_ANYONECANPAY | SIGHASH_NONE an
t; On 7/9/19 11:58 AM, Jonathan Underwood via bitcoin-dev wrote:
>
> Hi all,
>
> Just to be brief, I'll kick off with an attack scenario.
>
> 1. I am a signer, I get a PSBT that is ready to sign. I parse. I sign
> according to the PSBT as-is.
> 2. I notice my UTXO was sto
Hello All,
I have made a pull request based on the discussion currently. Please move
discussion there.
https://github.com/bitcoin/bips/pull/801
Thanks,
Jonathan
2019年6月29日(土) 17:11 Jonathan Underwood :
> Even if the difference is apparent outside the signed data (in the
> output). Signing the
My two cents:
1. Reserved types are awesome.
2. Varint for type is awesome.
3. BIP174 should specify a specific type for all (global, input, and
output) which means "see the BIP numbered in the next byte" so we can have
some sort of BIP43-ish system for BIP174... POR COMMITMENT and my current
sign
I would also like to agree that Signet should be a BIP.
Problem: Testnet is unreliable. *Testnet is used often for development of
Bitcoin*.
Proposal: To improve the dev environment for Bitcoin, let's create a new
kind of testnet that is more reliable.
I would also like to hear the logic behind "T
It is very common to set aside one or more "version slots" for proprietary
usage so that people adding their own features don't use version 7 only to
have the official BIP add a REAL version 7 a couple months later.
It makes perfect sense to just say "anyone adding their own stuff, format
your vers
18 matches
Mail list logo
