Re: [bitcoin-dev] Against proprietary and PoR fields in PSBT BIP174

2020-11-27 Thread Jonathan Underwood via bitcoin-dev
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

Re: [bitcoin-dev] Is Signet Bitcoin?

2019-10-15 Thread Jonathan Underwood via bitcoin-dev
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

Re: [bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE)

2019-07-24 Thread Jonathan Underwood via bitcoin-dev
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

Re: [bitcoin-dev] BIP174 amendment proposal (Important Signer Check should be mentioned)

2019-07-09 Thread Jonathan Underwood via bitcoin-dev
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 stolen b

[bitcoin-dev] BIP174 amendment proposal (Important Signer Check should be mentioned)

2019-07-09 Thread Jonathan Underwood via bitcoin-dev
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

Re: [bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE)

2019-06-29 Thread Jonathan Underwood via bitcoin-dev
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日(土)

Re: [bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE)

2019-06-29 Thread Jonathan Underwood via bitcoin-dev
ndividual xpubs of a > > > > > > > multisig warm wallet, and one key from that multisig is > > > > > > > compromized, attackers can then create a single-sig > > > > > > > destination address that they control, and move the coins > > > > > > > in a chain

Re: [bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE)

2019-06-28 Thread Jonathan Underwood via bitcoin-dev
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:

Re: [bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE)

2019-06-27 Thread Jonathan Underwood via bitcoin-dev
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

Re: [bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE)

2019-06-27 Thread Jonathan Underwood via bitcoin-dev
t; > > > > > destination address that they control, and move the coins > > > > > > > in a chain of two transactions, first to this single-sig > > > > > > > address, and then to an address that they independently > > > > &

Re: [bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE)

2019-06-27 Thread Jonathan Underwood via bitcoin-dev
' 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' word that hardware wallet > > > > > can show prominently before signing, or have

Re: [bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE)

2019-06-27 Thread Jonathan Underwood via bitcoin-dev
n 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 not want to regard a particular 'xpub >> >

Re: [bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE)

2019-06-27 Thread Jonathan Underwood via bitcoin-dev
> > using some form of 'vendor-specific', or 'metainformation-specific' > > > PSBT field. This way each usecase can be independently described in > > > its own documentation, that would include the particulars of the > > > format for the metainformation. This wou

Re: [bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE)

2019-06-26 Thread Jonathan Underwood via bitcoin-dev
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://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016917.html > > [2] > > https://lists.linuxf

[bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE)

2019-06-26 Thread Jonathan Underwood via bitcoin-dev
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

Re: [bitcoin-dev] BIP- & SLIP-0039 -- better multi-language support

2018-11-16 Thread Jonathan Underwood via bitcoin-dev
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

Re: [bitcoin-dev] BIP- & SLIP-0039 -- better multi-language support

2018-11-08 Thread Jonathan Underwood via bitcoin-dev
> 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