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

[Jonathan Underwood via bitcoin-dev]

Hi Andrew,

Ok, I will go ahead and write the amendment and make a PR.

Thanks!
Jon

2019年7月10日(水) 5:26 Andrew Chow :

> This was the original intent of the sighash field. Either the sighash is
> acceptable to the signer and the signer signs with it, or they do not sign
> at all.
>
> 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 by a hacker because they changed my PSBT
> input's sighashtype to SIGHASH_ANYONECANPAY | SIGHASH_NONE and after the
> fact they changed the outputs to send to themselves, and added an input
> they signed with SIGHASH_ALL.
> 3. I lose the BTC in my UTXO.
>
> So we should definitely add to the signer checks "ensure the sighash type
> given is the type of sighash you want to sign." etc.
>
> My proposal for a wording change would be addition to the bullet list:
>
> - If a sighash type is provided, the signer MUST check that the sighash
> type is acceptable to them, and fail signing if unacceptable.
> - If a sighash type is not provided, the signer SHOULD sign using
> SIGHASH_ALL, but may sign with any sighash type they wish.
>
> Any thoughts?
>
> Thanks,
> Jon
>
> --
> -
> Jonathan Underwood
> ビットバンク社 チーフビットコインオフィサー
> -
>
> 暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
>
> 指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
>
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Andrew Chow via bitcoin-dev]

This was the original intent of the sighash field. Either the sighash is 
acceptable to the signer and the signer signs with it, or they do not sign at 
all.

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 by a hacker because they changed my PSBT 
> input's sighashtype to SIGHASH_ANYONECANPAY | SIGHASH_NONE and after the fact 
> they changed the outputs to send to themselves, and added an input they 
> signed with SIGHASH_ALL.
> 3. I lose the BTC in my UTXO.
>
> So we should definitely add to the signer checks "ensure the sighash type 
> given is the type of sighash you want to sign." etc.
>
> My proposal for a wording change would be addition to the bullet list:
>
> - If a sighash type is provided, the signer MUST check that the sighash type 
> is acceptable to them, and fail signing if unacceptable.
> - If a sighash type is not provided, the signer SHOULD sign using 
> SIGHASH_ALL, but may sign with any sighash type they wish.
>
> Any thoughts?
>
> Thanks,
> Jon
>
> --
>
> -
> Jonathan Underwood
> ビットバンク社　チーフビットコインオフィサー
> -
>
> 暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
>
> 指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Tamas Blummer via bitcoin-dev]

Good morning ZmnSCPxj,

thank you very much for sharing your BCAN idea and thought process in detail.

I add some thoughs that very likely occured to you, but not formulated 
explicitelly:

1. The unique feature of such advertisement network is that it has no owner, 
just like the Bitcoin network.
If it had an owner, that owner could simply bill for use, but would also be 
forced to restrict access or apply some sort of censorship.
This is why usage costs is imposed through opportunity cost and not billed.

2. Since opportunity cost of one Bitcoin for a short time period is magnitudes 
less than its face value, one would need significant
Bitcoin amounts to impose meaningful costs so they have the chance to be 
included into BCANs purposedly limited bandwidth.
Those who would want to place an ad will often not have sufficient amount of 
Bitcoin holdings which lets them borrow UTXOs.

3. If borrowed Bitcoin is certain to be returned (as in your construction) then 
this offers riskless interest for HODLer.

4. Bitcoin’s most popular use is storing wealth whereby this use currently 
completely relies on the assumption that “the number goes up”.
A service that delivers interest on HODLed coins without exposing the HODLer to 
credit risk of the borrower is a huge game changer.

5.This scheme allows HODLer a concious decision whom or what project they fund.

For above reasons I think that this is a crucial design pattern to build 
censorship resistant networks which also give rise to riskless interest on 
Bitcoin.

My finance examples where abstract and less interesting for this audience but 
the BCAN should ring the bell for many.

As you said BCAN is possible with current Bitcoin, therefore we should no 
longer discuss it under the covenant topic.
The idea of debt covenant will likely resurface as soon as this design pattern 
proves to be useful in practice and one is looking for
a more flexible solution. I am confident we will get there, but not as fast as 
I initially thought.

Regards,

Tamas Blummer

> On Jul 9, 2019, at 12:31, ZmnSCPxj via bitcoin-dev 
>  wrote:
> 
> Good morning all,
> 
> I will attempt to restart my thinking from initial principles regarding my 
> proposed "Bitcoin Classified Ads Network".
> 
> Nodes behave this way:
> 
> * Nodes in this network gossip advertisements.
> * These advertisements refer to a UTXO that must be unspent at the chain tip 
> considered by each node, else they would be rejected.
> * The referred UTXO must contain a commitment to the text of the 
> advertisement, else the advertisement is rejected.
> * Nodes have a maximum limit on the total size of all advertisements they 
> retain and propagate to new nodes, or gossip to their peers.
>  This is a deliberate design decision.
> * If nodes exceed the above limit, they will sort advertisements according to 
> a value-rate, the value of the UTXO divided by the storage size of the 
> advertisement, and prune advertisements with low value-rate until they are 
> within the limit again.
> * Once the backing UTXO is spent, the advertisement is removed by nodes that 
> follow that chaintip.
> * As the name ***Classified Ads*** suggests, each advertisement also 
> indicates a "class" in which they belong to.
> 
> Then, from the above, we derive how a seller might behave.
> 
> * Sellers will attempt to put the minimum possible value into a UTXO 
> committing to an advertisement, to reduce the opportunity cost of using the 
> value elsewhere.
> * Thus the rent of the advertisement in this case is paid to joinmarket 
> makers and LN forwarding nodes, as the value used in a UTXO backing an 
> advertisement is not useable in joinmarket/LN.
> * Sellers remain in full control of their advertising UTXO, and can spend it 
> at any time.
> * Sellers may spend part of the UTXO and put the remaining funds into a 
> change address that is a new advertising UTXO, and re-transmit the 
> advertisement, this time pointing to the new change UTXO.
> * However, if the remaining change becomes too low, then its value-rate may 
> drop below the lowest value-rate that BCAN nodes will retain in their 
> (deliberately limited) storage, thus also deleting their advertisement from 
> the BCAN.
> * Presumably, the reason for advertising at all, is that the seller considers 
> the cost of advertising to be less than the expected gain of actually selling 
> their product.
> * Thus, even if the seller has the ability to spend the UTXO at any time, 
> they run the risk of spending too much and thus removing their advertisement 
> from the BCAN, and losing the expected gain of having the advertisement exist 
> on the BCAN.
> * A utility-maximizing seller would therefore not spend a minimal-value UTXO 
> backing the advertisement until it has gained the advantage of actually 
> selling the product, even if it has the option to do so: it is a forced move.
> * The cost of keeping the minimal-value UTXO unspent is the opportunity cost 
> in that the value may 

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

[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 and after the
fact they changed the outputs to send to themselves, and added an input
they signed with SIGHASH_ALL.
3. I lose the BTC in my UTXO.

So we should definitely add to the signer checks "ensure the sighash type
given is the type of sighash you want to sign." etc.

My proposal for a wording change would be addition to the bullet list:

- If a sighash type is provided, the signer MUST check that the sighash
type is acceptable to them, and fail signing if unacceptable.
- If a sighash type is not provided, the signer SHOULD sign using
SIGHASH_ALL, but may sign with any sighash type they wish.

Any thoughts?

Thanks,
Jon

-- 
-
Jonathan Underwood
ビットバンク社 チーフビットコインオフィサー
-

暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。

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

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

[ZmnSCPxj via bitcoin-dev]

Good morning all,

I will attempt to restart my thinking from initial principles regarding my 
proposed "Bitcoin Classified Ads Network".

Nodes behave this way:

* Nodes in this network gossip advertisements.
* These advertisements refer to a UTXO that must be unspent at the chain tip 
considered by each node, else they would be rejected.
* The referred UTXO must contain a commitment to the text of the advertisement, 
else the advertisement is rejected.
* Nodes have a maximum limit on the total size of all advertisements they 
retain and propagate to new nodes, or gossip to their peers.
  This is a deliberate design decision.
* If nodes exceed the above limit, they will sort advertisements according to a 
value-rate, the value of the UTXO divided by the storage size of the 
advertisement, and prune advertisements with low value-rate until they are 
within the limit again.
* Once the backing UTXO is spent, the advertisement is removed by nodes that 
follow that chaintip.
* As the name ***Classified Ads*** suggests, each advertisement also indicates 
a "class" in which they belong to.

Then, from the above, we derive how a seller might behave.

* Sellers will attempt to put the minimum possible value into a UTXO committing 
to an advertisement, to reduce the opportunity cost of using the value 
elsewhere.
* Thus the rent of the advertisement in this case is paid to joinmarket makers 
and LN forwarding nodes, as the value used in a UTXO backing an advertisement 
is not useable in joinmarket/LN.
* Sellers remain in full control of their advertising UTXO, and can spend it at 
any time.
* Sellers may spend part of the UTXO and put the remaining funds into a change 
address that is a new advertising UTXO, and re-transmit the advertisement, this 
time pointing to the new change UTXO.
* However, if the remaining change becomes too low, then its value-rate may 
drop below the lowest value-rate that BCAN nodes will retain in their 
(deliberately limited) storage, thus also deleting their advertisement from the 
BCAN.
* Presumably, the reason for advertising at all, is that the seller considers 
the cost of advertising to be less than the expected gain of actually selling 
their product.
* Thus, even if the seller has the ability to spend the UTXO at any time, they 
run the risk of spending too much and thus removing their advertisement from 
the BCAN, and losing the expected gain of having the advertisement exist on the 
BCAN.
* A utility-maximizing seller would therefore not spend a minimal-value UTXO 
backing the advertisement until it has gained the advantage of actually selling 
the product, even if it has the option to do so: it is a forced move.
* The cost of keeping the minimal-value UTXO unspent is the opportunity cost in 
that the value may have been used in joinmarket or LN instead.
* The minimum value will largely be dependent on how much the BCAN is used; 
more sellers advertising over BCAN will increase the minimum value.
* If the minimum value that is viable to keep its advertisement alive goes 
higher, then the opportunity cost of the seller using the same value elsewhere 
might exceed the expected gain from selling the product.
  However, this is expected of *any* advertising scheme: if the gains from 
selling is too small to justify the advertisement price, advertising does not 
happen; this is expected utility-maximizing behavior.
* If competitors of the seller exist and the BCAN node storage is already 
filled, competitors can increase the minimum value of a UTXO that can keep an 
advertisement alive on BCAN by simply adding more of their advertisements to 
BCAN.
* Thus we expect that, once the BCAN node storage is at or near the maximum 
value, the minimum value of a UTXO that can back an advertisement will approach 
the expected gain from selling the product.

Thus the system of simply committing UTXOs to particular advertisement texts 
seems sufficient to extract value from a seller wishing to advertise.
The purpose of this extraction of value is to ensure that spam does not 
overload the BCAN.

Let us now consider some kind of specialization, where a HODLer specializes in 
owning UTXOs, while an advertiser specializes in trading products that need 
advertising of some kind.

* We assume that the specialization means that the HODLer cannot feasibly make 
and sell products on its own, while the advertiser cannot own and control UTXOs 
of the minimum value needed to keep their advertisement alive on the BCAN.
* We assume that the specialization means that the advertiser can make and sell 
products for cheaper than the HODLer can, while the HODLer can own and control 
(and secure) UTXOs of the minimum value needed for advertisements to be kept 
alive, for cheaper than the advertiser can.

Then:

* A HODLer may offer to provide a UTXO locked by a 2-of-2 with a commitment to 
an advertisement of the advertiser's choosing, in exchange for rent of the 
value, plus an unbreakable promise to return the 

Re: [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY)

[Dmitry Petukhov via bitcoin-dev]

If you make ANYPREVOUTANYSCRIPT signature not the only signature that
controls this UTXO, but use it solely for restricting the spending
conditions such as the set of outputs, and require another signature
that would commit to the whole transaction, you can eliminate
malleability, for the price of additional signature, of course.

  CHECKSIG  CHECKSIG

(CHECKMULTISIG/CHECKSIGADD might be used instead)

where control-P can even be a pubkey of a key that is publicly known,
and the whole purpose of control-sig would be to restrict the outputs
(control-sig would be created with flags meaning ANYPREVOUTANYSCRIPT).
Because control-sig does not depend on the script and on the current
input, there should be no circular dependency, and it can be part of
the redeem script.

P would be the pubkey of the actual key that is needed to spend this
UTXO, and the signature of P can commit to all the inputs and outputs,
preventing malleability.

I would like to add that it may make sense to just have 2 additional
flags for sighash: NOPREVOUT and NOSCRIPT.

NOPREVOUT would mean that previous output is not committed to, and when
combined with ANYONECANPAY, this will mean ANYPREVOUT/NOINPUT:
ANYONECANPAY means exclude all inputs except the current, and NOPREVOUT
means exclude the current input. Thus NOPREVOUT|ANYONECANPAY = NOINPUT

With NOPREVOUT|ANYONECANPAY|NOSCRIPT you would have ANYPREVOUTANYSCRIPT

with NOPREVOUT|NOSCRIPT you can commit to "all the inputs beside the
current one", which would allow to create a spending restriction like
"this UTXO, and also one (or more) other UTXO", which might be useful
to retroactively revoke or transfer the rights to spend certain UTXO
without actually moving it:

think 'vault' UTXO that is controlled by Alice, but requires additional
'control' UTXO to spend. Alice have keys for both 'vault' UTXO, and
'control' UTXO, but Bob have only key for 'control' UTXO.

If Bob learnsthat Alice's vault UTXO key is at risk of compromize,
he spends the control UTXO, and then Alice's ability to spend vault
UTXO vanishes.

You can use this mechanism to transfer this right to spend if you
prepare a number of taproot branches with different pairs of (vault,
control) keys and a chain of transactions that each spend the previous
control UTXO such that the newly created UTXO becomes controlled by the
control key of the next pair, together with vault key in that pair.

В Sat, 22 Jun 2019 23:43:22 -0700
Jeremy via bitcoin-dev  wrote:

> This is insufficient: sequences must be committed to because they
> affect TXID. As with scriptsigs (witness data fine to ignore). NUM_IN
> too.
> 
> Any malleability makes this much less useful.
> --
> @JeremyRubin 
> 
> 
> 
> On Fri, Jun 21, 2019 at 10:31 AM Anthony Towns via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> > On Tue, Jun 18, 2019 at 04:57:34PM -0400, Russell O'Connor wrote:  
> > > So with regards to OP_SECURETHEBAG, I am also "not really seeing
> > > any  
> > reason to  
> > > complicate the spec to ensure the digest is precommitted as part
> > > of the opcode."  
> >
> > Also, I think you can simulate OP_SECURETHEBAG with an ANYPREVOUT
> > (NOINPUT) sighash (Johnson Lau's mentioned this before, but not
> > sure if it's been spelled out anywhere); ie instead of constructing
> >
> >   X = Hash_BagHash( version, locktime, [outputs], [sequences],
> > num_in )
> >
> > and having the script be " OP_SECURETHEBAG" you calculate an
> > ANYPREVOUT sighash for SIGHASH_ANYPREVOUTANYSCRIPT | SIGHASH_ALL:
> >
> >   Y = Hash_TapSighash( 0, 0xc1, version, locktime, [outputs], 0,
> >amount, sequence)
> >
> > and calculate a signature sig = Schnorr(P,m) for some pubkey P, and
> > make your script be "  CHECKSIG".
> >
> > That loses the ability to commit to the number of inputs or restrict
> > the nsequence of other inputs, and requires a bigger script (sig
> > and P are ~96 bytes instead of X's 32 bytes), but is otherwise
> > pretty much the same as far as I can tell. Both scripts are
> > automatically satisfied when revealed (with the correct set of
> > outputs), and don't need any additional witness data.
> >
> > If you wanted to construct "X" via script instead of hardcoding a
> > value because it got you generalised covenants or whatever; I think
> > you could get the same effect with CAT,LEFT, and RIGHT: you'd
> > construct Y in much the same way you construct X, but you'd then
> > need to turn that into a signature. You could do so by using pubkey
> > P=G and nonce R=G, which means you need to calculate
> > s=1+hash(G,G,Y)*1 -- calculating the hash part is easy, multiplying
> > it by 1 is easy, and to add 1 you can probably do something along
> > the lines of:
> >
> > OP_DUP 4 OP_RIGHT 1 OP_ADD OP_SWAP 28 OP_LEFT OP_SWAP OP_CAT
> >
> > (ie, take the last 4 bytes, increment it using 4-byte arithmetic,
> > then cat the first 28 bytes and the result. There's