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

[Dmitry Petukhov via bitcoin-dev]

In your proposed field key format,

{0x02}|{signing_pubkey}|{m}|{xpub}|...|{xpub}

I think you can replace the signing pubkey with just a fingerprint of
the master key, that would save 29 bytes per 0x02 field.

If the only entity that is concerned about the validity of the
signature is those that possess the signing_privkey, it will check the
signature when it sees the 0x02 field starting with its own key
fingerprint, and will ignore the field if the signature does not match.

If someone other than the signer needs to check that this xpub-package
was signed by certain cold key, it will need to know signing_pubkey
anyway, before it parses PSBT, as it won't have the means to check if
certain pubkey found in 0x02 field in PSBT is related to certain
signer, without knowing anything about the pubkey beforehand.

I'm not sure if the ability of unrelated parties to verify that
xpub-package matches its signature is useful in practice. 29 bytes per
0x02 field is not a big saving of space, and if this ability is actually
useful, the saving may not be worh loosing this ability.

Other note: you have 'unused' value of 1 for `m` in your scheme, why
not require m=1 for single-sig case, and use 0 as indicator that there
are a serlal number following it?

The key for the field would be encoded as

{0x02}|{signing_pubkey}|{m}|{xpub}|...|{xpub}

for usual case, and

{0x02}|{signing_pubkey}|0x00|{serial}|{m}|{xpub}|...|{xpub}

for the case when the signing scheme actually cares about different
versions of xpub packages signed by certain cold key

Going back to the idea of moving 'complex' usecases outside of BIP174:
maybe we could have a 'BIP-specific' field, that would have the key as

{0x0?}|{BIP-number}|{bip-specific-suffix-data}

so that the different usecases that are not general enough to be
included in BIP174 itself, may have their own BIPs. Vendor-specific
fields may also be done as a separate BIP.

В Thu, 27 Jun 2019 20:29:32 +0500
Dmitry Petukhov  wrote:

> Oh, I saw that you covered it in another mail:
> 
> > The expire / revoke problem is a larger problem than this feature
> > can handle.  
> 
> > In general, if one of the cold keys is stolen, there is rarely a
> > situation where you are completely sure the other cold keys haven't
> > been compromised... so the best practice would be all signers
> > generate new keys and all funds are moved to a completely new
> > multisig wallet (no common xpubs).  
> 
> The setup might not be 'all cold keys', but the keys with different
> levels of exposure to possible theft. In this config, compromise of
> one of the 'warm' keys might not necessary require changing the
> 'cold' key.
> 
> I'm not sure whether this usecase warrants adding extra 'serial'
> field, but on the other hand it is rather simple change, and those who
> does not care can always set 0. 
> 
> В Thu, 27 Jun 2019 18:14:29 +0500
> Dmitry Petukhov  wrote:
> 
> > What do you think about adding serial number to the xpub package ?
> > 
> > The key would be 
> > 
> > {0x02}|{signing_pubkey}|{serial}|{m}|{xpub}|...|{xpub}
> > 
> > and if the signer have the ability to store a counter, it can reject
> > 'outdated' xpub packages, and only accept those that was signed
> > using the serial number that it deems recent. This would allow a
> > limited mechanism to 'revoke' previously signed packages that have
> > compromized keys in them.
> > 
> > В Thu, 27 Jun 2019 17:16:14 +0900
> > Jonathan Underwood  wrote:
> >   
> > > I see what you mean.
> > > 
> > > What about this?
> > > https://github.com/junderw/bips/commit/57a57b4fae1ae14b77a2eebd99cd719148e3027e?short_path=82656c8#diff-82656c833e31e6751a412ce5e5c70920
> > > 
> > > Plus side: for single sig case, the key only increases by one byte
> > > (0x00 for the {m} value)
> > > 
> > > This way if it was 2 of 3 like before, you sign the whole "packet"
> > > so each key only signs the packet once. Way better than n!
> > > 
> > > Anywho. Please send your feedback. Thanks.
> > > Jonathan
> > > 
> > > 2019年6月27日(木) 16:27 Dmitry Petukhov :
> > > 
> > > > How would signer know that there _should_ be at least 3
> > > > signatures signed by the key owned by this signer ?
> > > >
> > > > If it does not know that it should enforce 2of3 multisig, for
> > > > example, the attacker that control only one key A can fool
> > > > signer B by sending to 1of1 single-sig that is derived from A's
> > > > xpub, and providing only sBxA in PSBT.
> > > >
> > > > If the signer does not have a hardcoded configuration that
> > > > will mandate a particular multisig scheme, it will allow sending
> > > > to any scheme.
> > > >
> > > > If the signer has a rich enough state to store updatable
> > > > configuration, it can just store the trusted xpubs directly.
> > > >
> > > > Alternatively, signer can sign not individual xpubs, but whole
> > > > xpub packages that correspond to particular multisig
> > > > configuration, and enforce that destination addresses correspond
> > > > to this 

Re: [bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve

[Tamas Blummer via bitcoin-dev]

Hi Eric,

Thank you for your questions as they show what concepts need further 
explanation, so you understand the potential of this proposal and how it is 
helpful to the ecosystem.

Riskless zero bond is in fact the most basic concept of financial engineering. 
Yes, there are engineers of finance, those who create and price financial 
derivatives (e.g. options, swaps) and structure products such as e.g. ABS, CDO 
etc.
I used to be one of them.

A zero bond formalizes the observation that 1 unit of currency in the future 
has different value than 1 unit available now. It is called riskless if it is 
certain to receive the payment in the future.
If we put this difference of vaue in relation to the amount then we get the 
“risk freee rate of return”, that you heard of.

E.g if one is willing to exchange 1 BTC unconditionally available now for 1.1 
BTC certainly available in a year but not earlier, then the implied “risk free 
rate of return” is apparently 10% pa. for Bitcoins.

The transaction I construct in the first example achives exactly this, because:

Bob forgoes his ability to use his unconditionally available coins by giving 
them to Alice with a covenant that ensures that Bob will receive them back 
later.
Bob does this because Alice pays for this in advance.

Alice can further transfer the coins encumbered by the covenant, but they will 
unconditionally return to Bob in the future.

The utility of these encumbered coins is that they prove that the loan is fully 
covered by reserves.

How valuable this utility is will be decided by the market and that value will 
be interest received by those who temporarily give up control. I am guess the 
value will be low but positive.

Lending does not mandate fractional or full reserves. These are choices the 
market or regulators enforce. Full reserve banking is not a fiction but is how 
things worked before introduction of gold receipts. A bank could only lend gold 
coins it possesed. Perils of fractional reserve were felt repeatedly by the 
Bitcoin ecnomy e.g. in the collaps of MtGox.

The idea to return to full reserve banking is not unique to gold bugs or 
Bitcoin but recently a popular vote was initiated in Switzerland to force Swiss 
banks to full reserves with respect to lending. This popular vote achived  24% 
support [1] which is quite remarkable if considered that the topic is not 
trivial as also our exchange shows.

I published today a writing in medium, that explains the concept of fractional 
vs. full reserve banking in conjunction with this proposal. Please read: 
https://medium.com/@tamas.blummer/full-reserve-banking-with-bitcoin-462b21ae9479
 


I would welcome feedback on the generalized covenant construct or its 
implementation, as I think it can open up much more uses than the few examples 
I gave.

Tamas Blummer

[1] Vollgeld Initiative: 
https://www.bfs.admin.ch/bfs/de/home/statistiken/politik/abstimmungen/jahr-2018/2018-06-10/vollgeld-initiative.html
 

> On Jun 28, 2019, at 19:25, Eric Voskuil  wrote:
> 
> Hi Tamas,
> 
> There are a number of economic assumptions contained herein. While I 
> understand you would like to focus on implementation, the worst bugs are 
> requirements bugs. IMO these should be addressed first. I’ve addressed some 
> possible issues inline.
> 
>> On Jun 28, 2019, at 01:27, Tamas Blummer via bitcoin-dev 
>> > > wrote:
>> 
>> I start with a formalisation of loans as common in finance:
>> 
>> A zero bond is a contract between two parties Alice and Bob whereby Alice 
>> receives an amount less than P and has to pay back P at a later time point 
>> called maturity.
>> The difference between the amount received and P is the interest implied by 
>> the contract. E.g. receiving 1 Bitcoin (> in a year is the same as getting a loan with 10% p.a. interest.
>> 
>> The inherent risk in the contract is that Alice may not honor the agreement 
>> or be bankrupt by then.
>> 
>> If we could programmatically guarantee that Alice honors the contract then 
>> we would be able to create a riskless zero bond, the fundation of financial 
>> engineering.
> 
> I’m not aware of the basis of this statement. While people use the term “risk 
> free rate of return” there has never actually been such a thing. It’s not 
> clear to me how a unicorn has been the foundation of “financial engineering”, 
> but I’m not also clear and what is intended by “engineering” in this sense. 
> Generally engineering is the implementation of higher level concepts. It is 
> those concepts that constitute requirements here.
> 
> At a minimum, interest cannot be guaranteed by this proposal, which implies 
> that at best it guarantees, setting aside changes in purchasing power, a 
> return of principle minus economic 

Re: [bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve

[Eric Voskuil via bitcoin-dev]

Hi Tamas,

There are a number of economic assumptions contained herein. While I understand 
you would like to focus on implementation, the worst bugs are requirements 
bugs. IMO these should be addressed first. I’ve addressed some possible issues 
inline.

> On Jun 28, 2019, at 01:27, Tamas Blummer via bitcoin-dev 
>  wrote:
> 
> I start with a formalisation of loans as common in finance:
> 
> A zero bond is a contract between two parties Alice and Bob whereby Alice 
> receives an amount less than P and has to pay back P at a later time point 
> called maturity.
> The difference between the amount received and P is the interest implied by 
> the contract. E.g. receiving 1 Bitcoin ( a year is the same as getting a loan with 10% p.a. interest.
> 
> The inherent risk in the contract is that Alice may not honor the agreement 
> or be bankrupt by then.
> 
> If we could programmatically guarantee that Alice honors the contract then we 
> would be able to create a riskless zero bond, the fundation of financial 
> engineering.

I’m not aware of the basis of this statement. While people use the term “risk 
free rate of return” there has never actually been such a thing. It’s not clear 
to me how a unicorn has been the foundation of “financial engineering”, but I’m 
not also clear and what is intended by “engineering” in this sense. Generally 
engineering is the implementation of higher level concepts. It is those 
concepts that constitute requirements here.

At a minimum, interest cannot be guaranteed by this proposal, which implies 
that at best it guarantees, setting aside changes in purchasing power, a return 
of principle minus economic interest on that principle (ie opportunity cost). 
Given that purchasing power changes over time, risk increases with the term of 
the loan. As such this is not riskless - both volatility and opportunity cost 
remain as risks.

> A systemic problem with loans is that the lender might operate on fractional 
> reserve, that is lending more than his capital.

This is not a systemic problem, this is the very nature of lending. Fractional 
reserve is simply a state banking term used to describe the fact that people 
invest (lend) a fraction of their savings and hoard the rest. It matters not 
that banks or individuals do this, credit expansion is inherent in economy. 
Without it there is no investment and therefore no production whatsoever.

> Unchecked inflation of money supply through fractional reserve is creating a 
> mess in the world we live in. Bitcoin could overcome this mess implementing 
> this proposal!

You seem to be conflating state banking with the effects of investing. Taxpayer 
support for bank investment creates both a moral hazard (and the resulting 
misallocation of capital to state-favored projects, creating the famed economic 
“business cycle”) and is a manifestation of persistent monetary inflation (ie 
seigniorage is a source taxation. Investment implies credit expansion, and the 
level of this expansion is controlled by time preference alone.

> I stop here with finance speak as the purpose of this mail is not to dive 
> into finance, but to show how loans with full reserve check could be 
> implemented in Bitcoin.
> 
> 1. Receiving the loan is a payment from Bob to Alice, but we need a 
> restriction how Alice can use the funds, so Bob can get them back 
> unconditionally at maturity, so lending is riskless to him.
> 2. Bob wants to receive interest, since he gives up his control of the coins 
> until maturity, he can not use them elsewhere until then. That interest could 
> be paid in advance, this can be solved with Bitcoin as is.

Interest cannot be paid in advance. This implies nothing more than a smaller 
amount of principle.

> How do we allow Alice to use the coins, that is: split/merge and transfer 
> them to others, but still ensure Bob can claim them back at maturity?
> 
> We ensure that Alice can only send the coins to outputs that inherit a 
> taproot path of validation (using http://bitcoin.sipa.be/miniscript/): 
> 'and(time(100),pk(C))' where C is Bob’s key and 100 is maturity
> 
> This requires a generalization of the Bitcoin Covenants Idea[1] such that it 
> nicely fits with taproot as follows:
> 
> 1. A covenant in the form of '_ covenant C’ on output means that it can be 
> spent to an output that maches the covenant pattern with placeholder _  and 
> the output(s) will be assigned 'covenant C'.
> 2. A covenant that mandates an output script with alternate validation paths 
> can also assign alternate covernants to be inherited by the output(s) 
> depending on which path was used to spend the input eg. 'covenant or(c 
> covenant C, d covernant D)’
> 3. The resulting covenant of outputs should be reduced following boolean 
> algebra, e.g. or(b,or(b,a)) to or(b, a)
> 4. express transitivity with 'covenant transitive’ which means the output 
> will have the same covenant as the input
> 5. allow to omit covenant on the output with 'covenant 

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

[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:
>
> > extended private key of the current signer derived from the
> > signer's root to m/2042083607'/959190427'/1400854130'/990526201'
>
> 1) The PSBT creator would need to know that private key, and the Coldcard,
> as a matter
>of policy, will never export a private subkey.
>

I think you have misunderstood. The signature inserted into this 0x02 field
is generated BY the signer (Coldkey) airgapped ahead of time. Then the
signature (and all the xpubs that were signed, since basically the "key"
value contains the "pubkey" and "message" while the "value" part has the
"signature". so all data items for verification are present.) will be
stored on the unsigned transaction preparing app. (MyTrezor dot com etc.
have an encrypted storage through Dropbox + encrypting with Trezor, so
they, for instance, could store the "whitelist signatures" on that dropbox
feature.


> 2) The 'm' in that path depends on who is reading the PSBT file, in the
> multisig
>case. Each cosigner would need a different version of the PSBT file


Again, this is the m of the signer's root. The signer should have an xprv,
or some sort of seed (a la BIP39 or aezeed or Electrum phrase etc.) that
gets turned into a xprv. That xprv is m in this case... in the case that
some offline signer is storing the xprv of some path like "xprv/25'/42'" or
something, then the signer's "identity" is whatever xprv that signer holds
and not any of the xprvs derived from that first xprv.

The reason we want only one HD key to sign it is because we want the signer
to be able to generate that path from the root xprv they hold, check that
the pubkey matched the pubkey for verification, then verify. Now the signer
knows "oh, I have signed this xpub / multisig setup before, therefore I
trust it"


> 3) XPUB's are big and hard to parse, and this addition is using lots of
> them.
>

Any app requiring this level of security would gladly add a few millisecond
for parsing some xpubs.
Any HD wallet that can sign using HD derived keys already has the necessary
tools to parse an xpub.


> 4) Coinjoins, and more complex script types, will want to authorize
>outputs that the PSBT signer may not fully understand. Your proposal
>would only help P2PKH and M-of-N multisig users.
>

Yes. This proposal is not a requirement. It is just a reservation for a
slot in the key-value scheme for a use case that many exchanges and
hardware wallets should implement. We have implemented something similar to
this using JSON format internally, but since HW wallet makers seem to be
moving toward PSBT adoption, I would love for this info to be possible to
be sent into an HW wallet so that Trezor etc. can implement this
"whitelist" type situation in a way that the Trezor can trust. (remember, a
"whitelist" that just lives in my trezor dot com website cache etc. is
prone to modification, whereas with my proposal the worst case is a hacker
deletes a signature, so Trezor doesn't trust something it should have, and
fails signing. It can not add itself to the "whitelist" without the HW
wallet private key.)

To fix, may I propose:
>
>
The following suggestions seems to be predicated on a misunderstanding of
my proposal, so I will hold off for now.


> - the signer and PSBT creator must share a pubkey/private key out of band
> (setup time)
> - the origin of that key is out of scope of this standard (but it could be
> derived via BIP32)
> - the PSBT creator can, optionally, sign any or all output sections by
> number using that key
>
> I would prefer the signatures are in the global section, and the
> signature is over all the bytes in the indicated output section,
> as originally serialized when it came into the signer's possession.
>
> We should be able to support multiple signers for individual outputs,
> and also multiple signatures for the same output section. That would
> support different derived keys per co-signer, and also quorum
> approval or other policies like that.
>
> Afterthought: Might be good to allow signature over the unsigned
> transaction, or
> maybe it should be part of the signature always.
>
> ---
> Peter D. Gray  ||  Founder, Coinkite  ||  Twitter: @dochex  ||  GPG:
> A3A31BAD 5A2A5B10
>
> On Fri, Jun 28, 2019 at 11:44:15AM +0900, Jonathan Underwood wrote:
> > 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
> can
> > alter my PSBT before signing, they could replace my change address with
> > their 

[bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve

[Tamas Blummer via bitcoin-dev]

I start with a formalisation of loans as common in finance:

A zero bond is a contract between two parties Alice and Bob whereby Alice 
receives an amount less than P and has to pay back P at a later time point 
called maturity.
The difference between the amount received and P is the interest implied by the 
contract. E.g. receiving 1 Bitcoin (http://bitcoin.sipa.be/miniscript/): 
'and(time(100),pk(C))' where C is Bob’s key and 100 is maturity

This requires a generalization of the Bitcoin Covenants Idea[1] such that it 
nicely fits with taproot as follows:

1. A covenant in the form of '_ covenant C’ on output means that it can be 
spent to an output that maches the covenant pattern with placeholder _  and the 
output(s) will be assigned 'covenant C'.
2. A covenant that mandates an output script with alternate validation paths 
can also assign alternate covernants to be inherited by the output(s) depending 
on which path was used to spend the input eg. 'covenant or(c covenant C, d 
covernant D)’
3. The resulting covenant of outputs should be reduced following boolean 
algebra, e.g. or(b,or(b,a)) to or(b, a)
4. express transitivity with 'covenant transitive’ which means the output will 
have the same covenant as the input
5. allow to omit covenant on the output with 'covenant drop'

The covenant Bob would assign to the loan output sent to Alice is: 'covenant 
or(and(time(100),pk(Bob)) covenant drop, _ covenant transitive)' which means:
- Alice can send to an output script where she is free to chose the embedded 
script at the placeholder _ and that output will again have the same covenant 
as the input.
- After maturity Bob can claim any coin that is transitively rooted in the loan 
(more on this later) and the covenant will no longer be assigned to his new 
output(s).

Assuming Alice wants to send some of the borrowed coins to Charlie:

for shorter notation lets use b='and(time(100),pk(Bob)) covenant drop’ for the 
script that gives Bob control after maturity.

Alice can not send to pk(Charlie), but she can send to or(b, pk(Charlie) 
covenant transitive)
Sending to pk(Charlie) would be sending cash, sending to or(b, pk(Charlie) 
covenant transitive) is a promissory note issued by Alice to Charlie, here is 
why:

If Charlie accepts an or(b, pk(Charlie) covenant transitive) output then he 
trusts, that Alice will offer a regular payment in exchange for it before 
maturity, since that output is worthless to Charlie after maturity as Bob can 
just take it.

It seems at the first sight that there is no value in these outputs for 
Charlie, since he still has to ensure Alice replaces them before maturity.

The value of these outputs to Charlie is the proof that he has exclusive 
control of the coins until maturity.
Alice can not issue promissory notes in excess of own capital or capital that 
she was able to borrow. No coin inflation or fractional reserve here, which 
also reduces the credit risk Charlie takes.

Due to the transitive covenant Charlie could pass on the coins to an other 
temporary owner until maturity when Bob would re-collect them unconditionally.

Should Charlie no longer be comfortable with Alice’s promise or need final 
coins (cash) immediatelly, then he could turn to Dan and do a re-purchase 
(repo) agreement with him.

Charlie would receive final coins from Dan in exchange for the temporarily 
controled coins and Charlie's promise to replace them with final coins before 
maturity.
Dan would thereby charge high interest through a discount since as he has to 
bear the credit risk of Charlie. This is not a riskless but a plain zero bond.

Why would Dan want to take temporary control of the coins at all? Again, to 
ensure Charlie is not doing yet another repo with Frank on the same coins, the 
sum of Charlie's repo deals are not in excess of his claims against others.
This again avoids lending in excess of coin supply and reduces the credit risk 
Dan takes.

Here are the sketches for the transacions for above alternate actions:

lets use shortcut c for 'or(and(time(100),pk(Bob)) covenant drop, _ covenant 
transitive)’

the transactions offer a fee of 0.0001

Bob gives a riskless credit to Alice:

Input   Output
1 pk(Bob)   1 or(b,pk(Alice) covenant c)
0.1 pk(Alice)   0. pk(Bob)

Alice could send a 0.5 promissory note to Charlie:

Input   Output
1 or(pk(Alice) covenant c)  0.5 or(b,pk(Charlie) covenant c)
1 pk(Alice) 0.5 or(b,pk(Alice) covenant c)
0. pk(Alice)

Alice could make good of the note before maturity, pay some interest and get 
back temporary control of the coins with:
Input   Output
0.5 or(b,pk(Charlie) covenant c)0.5 or(b,pk(Alice) covenant c)
0.5101 pk(Alice)0.51 pk(Charlie)

alternatively Charlie borrows from Dan at high interest:

Input 

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

[Peter D. Gray via bitcoin-dev]

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:

> extended private key of the current signer derived from the
> signer's root to m/2042083607'/959190427'/1400854130'/990526201'

1) The PSBT creator would need to know that private key, and the Coldcard, as a 
matter
   of policy, will never export a private subkey.

2) The 'm' in that path depends on who is reading the PSBT file, in the multisig
   case. Each cosigner would need a different version of the PSBT file.

3) XPUB's are big and hard to parse, and this addition is using lots of them.

4) Coinjoins, and more complex script types, will want to authorize
   outputs that the PSBT signer may not fully understand. Your proposal
   would only help P2PKH and M-of-N multisig users.

To fix, may I propose:

- the signer and PSBT creator must share a pubkey/private key out of band 
(setup time)
- the origin of that key is out of scope of this standard (but it could be 
derived via BIP32)
- the PSBT creator can, optionally, sign any or all output sections by number 
using that key

I would prefer the signatures are in the global section, and the
signature is over all the bytes in the indicated output section,
as originally serialized when it came into the signer's possession.

We should be able to support multiple signers for individual outputs,
and also multiple signatures for the same output section. That would
support different derived keys per co-signer, and also quorum
approval or other policies like that.

Afterthought: Might be good to allow signature over the unsigned transaction, or
maybe it should be part of the signature always.

---
Peter D. Gray  ||  Founder, Coinkite  ||  Twitter: @dochex  ||  GPG: A3A31BAD 
5A2A5B10

On Fri, Jun 28, 2019 at 11:44:15AM +0900, Jonathan Underwood wrote:
> 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 can
> alter my PSBT before signing, they could replace my change address with
> their address, and my signer would not know unless the signer just guesses
> all the path sets it knows, then derives thousands of change addresses and
> searches (most likely a signer is offline, so gap limit doesn't work since
> we can't tell which change addresses have tx history. So the 0x01 global
> tag will tell the signer "here's how you get from your master private key
> to the xpub used in the change output's output BIP32_DERIVATION tag... you
> can then derive the same key and check it is yours before signing."
> 
> Back to my proposal, this problem extends across wallets, since,
> for example, if I want to send from my cold wallet to my warm wallet, I
> don't want to give my cold signer my warm master key just so it can derive
> and check the key. That's what signatures are for. So this proposal says "A
> signer can be built to only sign if it sees a signature that itself has
> signed, then from that signed xpub(s) derives the BIP32_DERIVATION in the
> outputs, and if the output doesn't match it will reject and not sign"
> 
> This creates a sort of "chain of trust" for the wallet.
> 
> Currently the best way to prevent this (hacker swapping the send to
> address) without using signatures is to reuse the same address every time
> you want to send to the warm wallet, since after a few times, the signers
> (people) will be able to remember the address.
> 
> This is a huge HD drawback for high security requirement environments.
> Having this data in the PSBT standard will allow Trezor etc. to create an
> enforceable whitelist feature.
> 
> Let me know if you have feedback on the details.
> 
> Thanks,
> Jon
> 
> 2019年6月28日(金) 0:07 Peter D. Gray :
> 
> > I haven't studied the new proposal in depth, but my first impression is:
> >
> > Wouldn't it just be easier and better to just sign the entire "outputs"
> > section of the PSBT?
> >
> > The signature would cover every byte, and therefore would cover any
> > future BIP additions to the outputs area, and also help non-multisig
> > cases today.
> >
> > ---
> > Peter D. Gray  ||  Founder, Coinkite  ||  Twitter: @dochex  ||  GPG:
> > A3A31BAD 5A2A5B10
> >
> >
> 
> -- 
> -
> Jonathan Underwood
> ビットバンク社 チーフビットコインオフィサー
> -
> 
> 暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
> 
> 指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Taproot proposal

[Russell O'Connor via bitcoin-dev]

Hmm? If I'm following what you mean, that's not the P2P rules, it's the
> Unserialize code, in particular:
>
>   compat/assumptions.h:52:static_assert(sizeof(int) == 4, "32-bit int
> assumed");
>
>   serialize.h:289:uint64_t ReadCompactSize(Stream& is)
>
>   serialize.h-679-template typename V>
>   serialize.h-680-void Unserialize_impl(Stream& is, prevector& v,
> const V&)
>   serialize.h-681-{
>   serialize.h-682-v.clear();
>   serialize.h:683:unsigned int nSize = ReadCompactSize(is);
>
>   (and other Unserialize_impl implementations)
>
> However, ReadCompactSize throws "size too large" if the return value is
> greater than MAX_SIZE == 0x0200 =~ 33.5M, which prior to the implicit
> cast to 32 bits in Unserialize_impl. And it looks like that check's been
> there since Satoshi...
>
> So as far as I can see, that encoding's just unsupported/invalid, rather
> than equivalent/non-canonical?
>

Thanks for this correction!  I totally missed that MAX_SIZE == 0x0200.
I think I mistook it for SIZE_MAX when reviewing this, or just didn't
notice it at all.

Cheers,
> aj
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Taproot proposal

[Anthony Towns via bitcoin-dev]

On Wed, Jun 26, 2019 at 08:08:01PM -0400, Russell O'Connor via bitcoin-dev 
wrote:
> I have a comment about the 'input_index' of the transaction digest for taproot
> signatures.  It is currently listed as 2 bytes.  I think it would be better to
> expand that to 4 bytes.

FWIW, I think this would be essentially free, at least for the current
sighash modes, as (I think) all the non-ANYONECANPAY modes have at least
4 bytes of sha256 padding at present.

In addition to (or, perhaps, as a special case of) the reasons Russell
gives, I think this change would also better support proof-of-reserves
via taproot signatures (cf [0] or BIP 127), as it would allow the proof
tx to include more than 65k utxos with each utxo being signed with a
signature that commits to all inputs including the invalid placeholder.

[0] 
https://blockstream.com/2019/02/04/en-standardizing-bitcoin-proof-of-reserves/

If you didn't have this, but wanted to do proof-of-reserves over >65k
taproot UTXOs, you could use ANYONECANPAY signatures, and use the output
amounts to ensure the signatures can't be abused, something like:

   inputs:
 0: spend from txid .. vout 0, no witness data
 1: utxo1, signed with ANYONECANPAY|ALL
 2: utxo2, signed with ANYONECANPAY|ALL
 3: utxo3, signed with ANYONECANPAY|ALL
 [etc]

   outputs:
 0: sum(utxo1..utxoN), pay to self
 1: 209997690001-sum(utxo1..utxo3), payable to whatever

The total output value is therefore one satoshi more bitcoin than there
could ever have been, so none of the utxoK signatures can be reused on the
blockchain (unless there's severe inflation due to bugs or hardforks),
but the values (and sums) all remain less than 21M BTC so it also won't
fail the current "amount too big" sanity checks.

That seems a bit more fragile/complicated than using SIGHASH_ALL for
everything, though it means your cold wallet doesn't have to serialize
your >65k transactions to verify it's signing what it thinks it is.

> [1]The var-integer field for the number of inputs (and the number of outputs)
> in a transaction looks like it should allow upto 2^64-1 inputs; however this 
> is
> an illusion.  The P2P rules dictate that these values are immediately taken
> modulo 2^32 after decoding.  For example, if the number of inputs is a
> var-integer encoding of 0x010001, it is actually just a non-canonical way
> of encoding that there is 1 input.  Try this at home!

Hmm? If I'm following what you mean, that's not the P2P rules, it's the
Unserialize code, in particular:

  compat/assumptions.h:52:static_assert(sizeof(int) == 4, "32-bit int assumed");

  serialize.h:289:uint64_t ReadCompactSize(Stream& is)

  serialize.h-679-template
  serialize.h-680-void Unserialize_impl(Stream& is, prevector& v, const 
V&)
  serialize.h-681-{
  serialize.h-682-v.clear();
  serialize.h:683:unsigned int nSize = ReadCompactSize(is);

  (and other Unserialize_impl implementations)

However, ReadCompactSize throws "size too large" if the return value is
greater than MAX_SIZE == 0x0200 =~ 33.5M, which prior to the implicit
cast to 32 bits in Unserialize_impl. And it looks like that check's been
there since Satoshi...

So as far as I can see, that encoding's just unsupported/invalid, rather
than equivalent/non-canonical?

Cheers,
aj

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev