Re: [bitcoin-dev] Proof of reserves - recording

[Eric Voskuil via bitcoin-dev]

All reasonable.

e

> Okay, it seems to me that what you are saying is something like this:
> 
> > Proof-of-reserves would (partially) work for a "pure" warehousing service
> (i.e. user pays some fee, service keeps money and provides proofs that
> money is kept).
> > However, "pure" warehousing is not what a typical exchange does (else
> the explicit fees in their exchanges would be higher), as it takes on risk due
> to having to deal with non-Bitcoin monopoly money (by definition, since they
> are *exchanges*).
> > Further, with Bitcoin you can be your own warehouse (including Green-like
> multisig schemes where you own your own keys that are part of the
> scheme), which is an alternative choice to hiring a "pure warehouse" (i.e.
> Safe Deposit).
> 
> Would that be a fair (if somewhat rough and undetailed) restatement?
> 
> Regards,
> ZmnSCPxj


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

Re: [bitcoin-dev] A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent

[Anthony Towns via bitcoin-dev]

On Fri, Jul 09, 2021 at 09:19:45AM -0400, Antoine Riard via bitcoin-dev wrote:
> > The easy way to avoid O(n^2) behaviour in (3) is to disallow partial
> > overlaps. So let's treat the tx as being distinct bundles of x-inputs
> > and y-outputs, and we'll use the annex for grouping, since that is
> > committed to by singatures. Call the annex field "sig_group_count".
> > When processing inputs, setup a new state pair, (start, end), initially
> > (0,0).
> > When evaluating an input, lookup sig_group_count. If it's not present,
> > then set start := end. If it's present and 0, leave start and end
> > unchanged. Otherwise, if it's present and greather than 0, set
> > start := end, and then set end := start + sig_group_count.
> IIUC the design rationale, the "sig_group_count" lockdowns the hashing of
> outputs for a given input, thus allowing midstate reuse across signatures
> input.

No midstates, the message being signed would just replace
SIGHASH_SINGLE's:

  sha_single_output: the SHA256 of the corresponding output in CTxOut
  format

with

  sha_group_outputs: the SHA256 of the serialization of the group
  outputs in CTxOut format.

ie, you'd take span{start,end}, serialize it (same as if it were
a vector of just those CTxOuts), and sha256 it.

> Let's say you want to combine {x_1, y_1} and {x_2, y_2} where {x, y} denotes
> bundles of Lightning commitment transactions.
> x_1 is dual-signed by Alice and Bob under the SIGHASH_GROUP flag with
> `sig_group_count`=3.
> x_2 is dual-signed by Alice and Caroll under the SIGHASH_GROUP flag, with
> `sig_group_count`=2.
> y_1 and y_2 are disjunctive.
> At broadcast, Alice is not able to combine {x_1,y_1} and {x_2, y_2} for the
> reason that x_1, x_2 are colliding on the absolute output position.

So the sha256 of the span of the group doesn't commit to start and end
-- it just serializes a vector, so commits to the number of elements,
the order, and the elements themselves. So you're taking serialize(y_1)
and serialize(y_2), and each of x_1 signs against the former, and each
of x_2 signs against the latter.

(Note that the annex for x_1_0 specifies sig_group_count=len(y_1)
and the annex for x_1_{1..} specifies sig_group_count=0, for "reuse
previous input's group", and the signatures for each input commit to
the annex anyway)

> One fix could be to skim the "end > num_ouputs" semantic,

That's only there to ensure the span doesn't go out of range, so I don't
think it makes any sense to skip it?

> I think this SIGHASH_GROUP proposal might solve other use-cases, but if I
> understand the semantics correctly, it doesn't seem to achieve the batch
> fee-bumping of multiple Lightning commitment with O(1) onchain footprint I was
> thinking of for IOMAP...

Does the above resolve that?

Cheers,
aj

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

Re: [bitcoin-dev] Proof of reserves - recording

[ZmnSCPxj via bitcoin-dev]

Good morning e,

Okay, it seems to me that what you are saying is something like this:

> Proof-of-reserves would (partially) work for a "pure" warehousing service 
> (i.e. user pays some fee, service keeps money and provides proofs that money 
> is kept).
> However, "pure" warehousing is not what a typical exchange does (else the 
> explicit fees in their exchanges would be higher), as it takes on risk due to 
> having to deal with non-Bitcoin monopoly money (by definition, since they are 
> *exchanges*).
> Further, with Bitcoin you can be your own warehouse (including Green-like 
> multisig schemes where you own your own keys that are part of the scheme), 
> which is an alternative choice to hiring a "pure warehouse" (i.e. Safe 
> Deposit).

Would that be a fair (if somewhat rough and undetailed) restatement?

Regards,
ZmnSCPxj

> > Good morning e,
>
> Good afternoon Z.
>
> > > Any expectation of interest implies borrowing, in other words, a loan 
> > > to
> > >
> >
> > the bank.
> > Perhaps this is the key point of contention?
>
> I'm not sure, but from my observations it's long been a point of confusion in 
> Bitcoiner understanding of banking.
>
> To put a finer point on it, Rothbard's criteria is a vague in a couple ways. 
> Earnings that offset fees are also "interest" in the economic context - in 
> which he writes. So even a zero-interest account (or negative up to the full 
> cost of maintaining the account) qualifies under this criterion. Yet he is 
> careful to say "implies". The arrangement may of course be explicit, in which 
> case one no longer relies on implied contract, one relies on explicit 
> contract. Finally, one may "expect" no interest, and even pay fees, but it 
> may nonetheless be a loan. This is what contracts are for.
>
> If one contracts for warehousing service, such Safe Deposit, as opposed to a 
> time deposit, such as Certificate of Deposit, Savings Account, or Checking 
> Account, then one gets a warehousing service - full fees and a contractual 
> obligation to maintain 100% of the deposit. There are also money transmission 
> services that move money around for a fee. The inability to distinguish money 
> from credit (including money substitutes) and warehousing from investment 
> (including "banking") leads directly to false conclusions regarding money and 
> banking. Unfortunately a good number of self-described "Austrians" perpetuate 
> these errors.
>
> > In cases where Bitcoin is given over to an exchange, there is no expectation
> > of interest, at least in the sense that there is no expectation that the 
> > number
> > of Bitcoins deposited in the exchange increase over time.
> > (There may be an expectation of an increase in the number of green-ink
> > historical commemoration papers it can buy, but the point is that the number
> > of Bitcoins held in behalf of the user is not expected to change)
> > The expectation is that exchanges earn money from the difference between
> > buy-price and sell-price, and the money-warehousing service they provide is
> > simply provided for free to facilitate their main business (i.e. brokers for
> > exchange).
> > Thus, the expectation is that the exchange provides a warehouse service,
> > not a bank service, and this service is provided for free since it enables 
> > their
> > real business of earning from bid-ask spreads.
>
> I'm not aware of what are people's expectations, nor would I judge what 
> qualifies as someone's "real" business, but a warehouse that facilitates 
> trades for a fee is of course a possible business model. PayPal's intended 
> (real?) business model was to earn from the float. That didn't pan out, 
> because people didn't retain money in their transmitter service.
>
> Exchanges that deal in monopoly money must move this through traditional 
> finance. This incurs all manner of risk. When someone sends them monopoly 
> money, there is no crypto-surety possible. This is part of their "reserve" 
> just as is the other side of trades.
>
> What matters is what people contract for - agree to, voluntarily.
>
> > On the other hand, not your keys not your coins, so anyone who uses such a
> > warehouse has whatever happens to the funds coming for them...
>
> One of the essential benefits of Bitcoin being that you can be your own 
> warehouse, and be your own money transmitter.
>
> But all production requires investment, which inherently entails letting go 
> of your money, producing something with it, and selling it to people for 
> other money. All investment is from someone's "reserve". Full reserve 
> investment (including banking) is an oxymoron. So whether through exchanges 
> or otherwise, there will be production, risk, loss and earnings. Otherwise 
> there will be nothing at all to buy, and all money will be worthless. This 
> idea of assuring that money is fully reserved applies only to that which one 
> does not invest (one's hoard); it does not apply to banks, or the capital of 
> any other compan

Re: [bitcoin-dev] Proof of reserves - recording

[Eric Voskuil via bitcoin-dev]

> Good morning e,

Good afternoon Z.

> > Any expectation of interest implies borrowing, in other words, a loan to
> the bank.
> 
> Perhaps this is the key point of contention?

I'm not sure, but from my observations it's long been a point of confusion in 
Bitcoiner understanding of banking.

To put a finer point on it, Rothbard's criteria is a vague in a couple ways. 
Earnings that offset fees are also "interest" in the economic context - in 
which he writes. So even a zero-interest account (or negative up to the full 
cost of maintaining the account) qualifies under this criterion. Yet he is 
careful to say "implies". The arrangement may of course be explicit, in which 
case one no longer relies on implied contract, one relies on explicit contract. 
Finally, one may "expect" no interest, and even pay fees, but it may 
nonetheless be a loan. This is what contracts are for.

If one contracts for warehousing service, such Safe Deposit, as opposed to a 
time deposit, such as Certificate of Deposit, Savings Account, or Checking 
Account, then one gets a warehousing service - full fees and a contractual 
obligation to maintain 100% of the deposit. There are also money transmission 
services that move money around for a fee. The inability to distinguish money 
from credit (including money substitutes) and warehousing from investment 
(including "banking") leads directly to false conclusions regarding money and 
banking. Unfortunately a good number of self-described "Austrians" perpetuate 
these errors.

> In cases where Bitcoin is given over to an exchange, there is no expectation
> of interest, at least in the sense that there is no expectation that the 
> number
> of Bitcoins deposited in the exchange *increase* over time.
> (There may be an expectation of an increase in the number of green-ink
> historical commemoration papers it can buy, but the point is that the number
> of Bitcoins held in behalf of the user is not expected to change)
> 
> The expectation is that exchanges earn money from the difference between
> buy-price and sell-price, and the money-warehousing service they provide is
> simply provided for free to facilitate their *main* business (i.e. brokers for
> *exchange*).
> Thus, the expectation is that the exchange provides a warehouse service,
> not a bank service, and this service is provided for free since it enables 
> their
> *real* business of earning from bid-ask spreads.

I'm not aware of what are people's expectations, nor would I judge what 
qualifies as someone's "real" business, but a warehouse that facilitates trades 
for a fee is of course a possible business model. PayPal's intended (real?) 
business model was to earn from the float. That didn't pan out, because people 
didn't retain money in their transmitter service. 

Exchanges that deal in monopoly money must move this through traditional 
finance. This incurs all manner of risk. When someone sends them monopoly 
money, there is no crypto-surety possible. This is part of their "reserve" just 
as is the other side of trades.

What matters is what people contract for - agree to, voluntarily.

> On the other hand, not your keys not your coins, so anyone who uses such a
> warehouse has whatever happens to the funds coming for them...

One of the essential benefits of Bitcoin being that you can be your own 
warehouse, and be your own money transmitter.

But all production requires investment, which inherently entails letting go of 
your money, producing something with it, and selling it to people for other 
money. All investment is from someone's "reserve". Full reserve investment 
(including banking) is an oxymoron. So whether through exchanges or otherwise, 
there will be production, risk, loss and earnings. Otherwise there will be 
nothing at all to buy, and all money will be worthless. This idea of assuring 
that money is fully reserved applies only to that which one does not invest 
(one's hoard); it does not apply to banks, or the capital of any other 
companies. If it can help people feel better about their Safe Deposit 
(warehousing), I'm all for it. But if one wants a 20% bitcoin reserve, one can 
certainly place 20% into cold storage.

> And of course exchanges need not earn money *just* from bid-ask spreads
> *in practice*, so they are unlikely to provide proof-of-reserves either.

If they did not earn money as a bank, the explicit cost of their services would 
be that much higher. Which people prefer is of course entirely up to them. I 
don't know which is more likely.

> Indeed, money warehousing may very well be provided by means other than
> proof-of-reserves, such as by using multisig the way Green wallet does, with
> better security.

Right, this is an aspect of using your own wallet.

> Perhaps "pure exchanges" would be more amenable to such a scheme
> rather than proof-of-reserves.

Or simply pairing traders, which is of course an existing model.

Best,
e

> Regards,
> ZmnSCPxj

_

Re: [bitcoin-dev] Proof of reserves - recording

[ZmnSCPxj via bitcoin-dev]

Good morning e,


> Any expectation of interest implies borrowing, in other words, a loan to 
> the bank.

Perhaps this is the key point of contention?

In cases where Bitcoin is given over to an exchange, there is no expectation of 
interest, at least in the sense that there is no expectation that the number of 
Bitcoins deposited in the exchange *increase* over time.
(There may be an expectation of an increase in the number of green-ink 
historical commemoration papers it can buy, but the point is that the number of 
Bitcoins held in behalf of the user is not expected to change)

The expectation is that exchanges earn money from the difference between 
buy-price and sell-price, and the money-warehousing service they provide is 
simply provided for free to facilitate their *main* business (i.e. brokers for 
*exchange*).
Thus, the expectation is that the exchange provides a warehouse service, not a 
bank service, and this service is provided for free since it enables their 
*real* business of earning from bid-ask spreads.

On the other hand, not your keys not your coins, so anyone who uses such a 
warehouse has whatever happens to the funds coming for them...

And of course exchanges need not earn money *just* from bid-ask spreads *in 
practice*, so they are unlikely to provide proof-of-reserves either.

Indeed, money warehousing may very well be provided by means other than 
proof-of-reserves, such as by using multisig the way Green wallet does, with 
better security.
Perhaps "pure exchanges" would be more amenable to such a scheme rather than 
proof-of-reserves.

Regards,
ZmnSCPxj

>
> "Whether saved capital is channeled into investments via stocks or via 
> loans is unimportant. The only difference is in the legal technicalities. 
> Indeed, even the legal difference between the creditor and the owner is a 
> negligible one."
>
> -   Rothbard
>
> > You're using terms in non-standard ways. Putting money into a bank is not 
> > considered "lending" to the bank.
>
> I think it's quite clear that Rothbard considers it lending. I'm not big on 
> appeal to authority, but sometimes it helps open minds. Links here:
>
> https://github.com/libbitcoin/libbitcoin-system/wiki/Full-Reserve-Fallacy
>
> > > money markets have had no reserve requirement and have a nearly spotless 
> > > record of satisfying their obligations.
>
> > Lol, money markets are so new that they've had no opportunity to show their 
> > true risk.
>
> 1971, 50 years.
> https://en.wikipedia.org/wiki/Money_market_fund
>
> > In the finance world, things work fine for a long time until they fail 
> > spectacularly, losing more than the gain they made in the first place. This 
> > is a regular occurence. Its the reason bitcoin was created.
>
> regular occurrence...
>
> "Buck breaking has rarely happened. Up to the 2008 financial crisis, only 
> three money funds had broken the buck in the 37-year history of money 
> funds... The first money market mutual fund to break the buck was First 
> Multifund for Daily Income (FMDI) in 1978, liquidating and restating NAV at 
> 94 cents per share"
>
> An investment loss of 6%.
>
> "The Community Bankers US Government Fund broke the buck in 1994, paying 
> investors 96 cents per share."
>
> An investment loss of 4%.
>
> "This was only the second failure in the then 23-year history of money funds 
> and there were no further failures for 14 years... No further failures 
> occurred until September 2008, a month that saw tumultuous events for money 
> funds."
>
> It was a "tumultuous" month for nearly all investments. The feds of course 
> doled out the pork, and the funds had to take it (as if their competition did 
> and they didn't they would fail due to higher relative capital costs and 
> thereby lower rates). In the past, absent pork, they had raised money where 
> necessary to maintain their NAV (just as banks do, but they go to the 
> taxpayer, and just as all business do from time to time).
>
> These are remarkably stable in terms of NAV. And people seem to be satisfied 
> with them:
>
> "At the end of 2011, there were 632 money market funds in operation,[19] with 
> total assets of nearly US$2.7 trillion.[19] Of this $2.7 trillion, retail 
> money market funds had $940 billion in Assets Under Management (AUM). 
> Institutional funds had $1.75 trillion under management.[19]"
>
> The point being, that this is as close to free market bank-based investing as 
> exists in the white market. In a money market fund, the NAV is reflected in 
> the share price, so any losses are evenly distributed - no different than 
> when all those HODLers take a hit when Elon farts, and the reserve they 
> maintain has been very effective in maintaining their $1/share target despite 
> paying interest on investments. They are merely shifting market returns into 
> interest, just like banks. Market returns over short periods aren't always 
> positive. No surprise. The larger point being, BANKS ARE INVESTMENT FUNDS.
>
> > 

Re: [bitcoin-dev] OP_CAT Makes Bitcoin Quantum Secure [was CheckSigFromStack for Arithmetic Values]

[Ethan Heilman via bitcoin-dev]

>To implement Winternitz we need some kind of limited-repeat construct, which 
>is not available in SCRIPT, but may be emulatable with enough `OP_IF` and 
>sheer brute force.
But what you gain in smaller signatures, you lose in a more complex
and longer SCRIPT, and there are limits to SCRIPT size (in order to
limit the processing done in each node).

Using depth 4 Winternitz would increase the number of instructions in
SCRIPT by 4*(signature bits/2) instructions, but decrease the
signature size by (signature bits/2) hash preimages. Given that
instructions are significantly smaller in size than the hash preimages
used, it seems like this would significantly reduce total size.

>Merkle signatures trade off shorter pubkeys for longer signatures (signatures 
>need to provide the hash of the *other* preimage you are not revealing), but 
>in the modern post-SegWit Bitcoin context both pubkeys and signatures are 
>stored in the witness area, which have the same weight, thus it is actually a 
>loss compared to Lamport.

I wasn't proposing using plain merkle signatures, rather I was
thinking about something where if particular chunks of the message fit
a pattern you could release a seed higher in the commitment tree. For
instance 1,1,1 could be signed as by releasing H(01||H(01||H(01||x))),
 H(11||H(11||H(11||x))), H(21||H(21||H(21||x))), or by releasing X.
However, you would want to only release X in that one specific case
(1,1,1) but no others. Again this would bloat the SCRIPT and decrease
signature size but at a favorable ratio.

I am not convinced anyone should do these things, but they are fun to
think about and I suspect with more thought such signature sizes and
SCRIPT sizes could be even further reduced.

On Fri, Jul 9, 2021 at 6:38 PM ZmnSCPxj  wrote:
>
> Good morning Ethan,
>
> > > Yes, quite neat indeed, too bad Lamport signatures are so huge (a couple 
> > > kilobytes)... blocksize increase cough
> >
> > Couldn't you significantly compress the signatures by using either
> > Winternitz OTS or by using OP_CAT to build a merkle tree so that the
> > full signature can be derived during script execution from a much
> > shorter set of seed values?
>
> To implement Winternitz we need some kind of limited-repeat construct, which 
> is not available in SCRIPT, but may be emulatable with enough `OP_IF` and 
> sheer brute force.
> But what you gain in smaller signatures, you lose in a more complex and 
> longer SCRIPT, and there are limits to SCRIPT size (in order to limit the 
> processing done in each node).
>
> Merkle signatures trade off shorter pubkeys for longer signatures (signatures 
> need to provide the hash of the *other* preimage you are not revealing), but 
> in the modern post-SegWit Bitcoin context both pubkeys and signatures are 
> stored in the witness area, which have the same weight, thus it is actually a 
> loss compared to Lamport.
>
>
> So yes, maybe Winternitz (could be a replacement for the "trinary" Jeremy 
> refers to), Merkle not so much.
>
> Regards,
> ZmnSCPxj
>
> > On Thu, Jul 8, 2021 at 4:12 AM ZmnSCPxj via bitcoin-dev
> > bitcoin-dev@lists.linuxfoundation.org wrote:
> >
> > > Good morning Jeremy,
> > > Yes, quite neat indeed, too bad Lamport signatures are so huge (a couple 
> > > kilobytes)... blocksize increase cough
> > > Since a quantum computer can derive the EC privkey from the EC pubkey and 
> > > this scheme is resistant to that, I think you can use a single well-known 
> > > EC privkey, you just need a unique Lamport keypair for each UTXO 
> > > (uniqueness being mandatory due to Lamport requiring preimage revelation).
> > > Regards,
> > > ZmnSCPxj
> > >
> > > > Dear Bitcoin Devs,
> > > > As mentioned previously, OP_CAT (or similar operation) can be used to 
> > > > make Bitcoin "quantum safe" by signing an EC signature. This should 
> > > > work in both Segwit V0 and Tapscript, although you have to use HASH160 
> > > > for it to fit in Segwit V0.
> > > > See my blog for the specific construction, reproduced below.
> > > > Yet another entry to the "OP_CAT can do that too" list.
> > > > Best,
> > > >
> > > > Jeremy
> > > >
> > > > ---
> > > >
> > > > I recently published a blogpost about signing up to a5 byte value using 
> > > > Bitcoin script arithmetic and Lamport signatures.
> > > > By itself, this is neat, but a little limited. What if we could sign 
> > > > longer
> > > > messages? If we can sign up to 20 bytes, we could sign a HASH160 digest 
> > > > which
> > > > is most likely quantum safe...
> > > > What would it mean if we signed the HASH160 digest of a signature? What 
> > > > the
> > > > what? Why would we do that?
> > > > Well, as it turns out, even if a quantum computer were able to crack 
> > > > ECDSA, it
> > > > would yield revealing the private key but not the ability to malleate 
> > > > the
> > > > content of what was actually signed. I asked my good friend and 
> > > > cryptographer
> > > > Madars Virza if my intuition was correct, and he
> > > > c

Re: [bitcoin-dev] Proof of reserves - recording

[Eric Voskuil via bitcoin-dev]

>> You can prove that in your own wallet. All other scenarios imply lending 
>> (which is what is implied by “reserve”) and lending cannot be 100% reserve.

>You're using terms in non-standard ways. Putting money into a bank is not 
>considered "lending" to the bank.

What people consider is irrelevant, all that matters is what is correct. A bank 
account as you are referring to it is indistinguishable from a money market 
(investment) fund in all aspects but federal reserve membership and regulatory 
controls. Interest (and offset expenses) derives directly from their earnings 
on this *investment*. Describing it otherwise is either an error (leading to 
false conclusions) or a lie.

> You may make a case that you're lending to a bank, and that they legally owe 
> you repayment of that money on demand limited by the terms you mentioned. But 
> regardless of a case that can be made there, pretty much no one considers 
> that "lending". Since you you like defining things legally, depositing money 
> in a bank is legally not defined as lending to the bank.

Please don’t bother to try and use statue as if it was at all relevant 
regarding economic concepts.

> So no, all other scenarios do not imply lending. You can have your coins in 
> custody with someone else, and that someone else can keep 100% reserves if 
> they choose (or agreed to) and can prove it to you via the method I described 
> or the methods others have linked to. 

That’s what Rothbard calls a “warehouse” - in order to distinguish it from 
investment. I’ve already made this distinction. Easier to prove with your own 
wallet, as I said. You are conflating this with banking, which should be 
obvious.

>> They are time deposits, read your bank agreement.

> You are 
> https://www.investopedia.com/terms/t/timedeposit.asp#:~:text=A%20time%20deposit%20is%20an,pre%2Dset%20date%20of%20maturity.&text=Time%20deposits%20generally%20pay%20a,of%20investment%20is%20term%20deposit..
>  
> https://www.slsp.sk/en/personal/faq/what-is-the-difference-between-a-term-deposit-and-savings-account
>  if you don't believe me. The only way you would be correct is if banks were 
> committing fraud and calling something a "savings account" when it isn't in 
> fact a savings account.

No, I am not wrong. It's not a question of believing you, it's a question of 
understanding the concepts. You will find this language in your deposit 
agreement (as required by statute):

"9. Our right to require advance notice of withdrawals
For all savings accounts and all personal interest-bearing checking accounts, 
we reserve the right to require seven days’ prior written notice of withdrawal."
https://www.chase.com/content/dam/chasecom/en/checking/documents/deposit_account_agreement.pdf

"When a man deposits goods at a warehouse, he is given a receipt and pays the 
owner of the warehouse a certain sum for the service of storage. He still 
retains ownership of the property; the owner of the warehouse is simply 
guarding it for him. When the warehouse receipt is presented, the owner is 
obligated to restore the good deposited. A warehouse specializing in money is 
known as a "bank.""
- Rothbard

As you can see, he is not talking about what you are talking about when it 
comes to colloquial use of the term "bank", he is clear to define what he means 
by "bank".

"Someone else's property is taken by the warehouse and used for its own 
money-making purposes. It is not borrowed, since no interest is paid for the 
use of the money."
- Rothbard

Any expectation of interest implies *borrowing*, in other words, a *loan* to 
the bank.

"Whether saved capital is channeled into investments via stocks or via loans is 
unimportant. The only difference is in the legal technicalities. Indeed, even 
the legal difference between the creditor and the owner is a negligible one."
- Rothbard

> You're using terms in non-standard ways. Putting money into a bank is not 
> considered "lending" to the bank.

I think it's quite clear that Rothbard considers it lending. I'm not big on 
appeal to authority, but sometimes it helps open minds. Links here:

https://github.com/libbitcoin/libbitcoin-system/wiki/Full-Reserve-Fallacy

>> money markets have had no reserve requirement and have a nearly spotless 
>> record of satisfying their obligations.

> Lol, money markets are so new that they've had no opportunity to show their 
> true risk.

1971, 50 years.
https://en.wikipedia.org/wiki/Money_market_fund

> In the finance world, things work fine for a long time until they fail 
> spectacularly, losing more than the gain they made in the first place. This 
> is a regular occurence. Its the reason bitcoin was created.

regular occurrence...

"Buck breaking has rarely happened. Up to the 2008 financial crisis, only three 
money funds had broken the buck in the 37-year history of money funds... The 
first money market mutual fund to break the buck was First Multifund for Daily 
Income (FMDI) in 1978, liquidating and rest

Re: [bitcoin-dev] OP_CAT Makes Bitcoin Quantum Secure [was CheckSigFromStack for Arithmetic Values]

[Jeremy via bitcoin-dev]

I thought about this, but at the time of writing I couldn't come up with
something I thought was substantially better. I spent a few more cycles
thinking on it -- you can definitely do better. It's not clear how much
better Winternitz might be, or if it would be secure in this context?
Here's some exploration...

maybe you can do something like:

   || IF SWAP HASH SWAP ELSE HASH FROMALTSTACK
<2**n> TOALTSTACK ADD ENDIF CAT

you can process this (assume HASH160) into chunks of 26 bits, cat them all
together, and then stash that hash. You would need 6 gadgets, and then 1
overflow + 4 bare hashes for the final key hash (e.g. your tree looks like)
H(H(26x20) || H(26x20)...H(bit)|| H(bit) || H(bit) || H(bit)). It doesn't
make sense to have a "nice" merkle tree, just fit in as much data as
possible per call (520 bytes). If OP_SHASTREAM, this is even better since
you can ignore structuring...

This would bring your cost down by about 20 bytes per bit, for 160 bits, so
around a savings of 3200 bytes... not bad! 1/3 cheaper.

Script is about 15x160 = 2400 and change, witness is 43x160 = 6880

If you were to convert to 3-ary, you could cut this down to 101 gates with
a script like:

witnesses:
<0> 
 <1> 
  <2> 

script:
HASH SWAP
IFDUP
NOTIF# 0 passed in (0)
SWAP CAT
ELSE
<3**n> TOALT
1SUB
IF # 2 passed in (+1)
FROMALT # do nothing
ELSE # 1 passed in (T)
SWAP # Swaps H(xT) to back
FROMALT NEGATE # negate
END
FROMALT ADD TOALT # add to accumulator
ENDIF
CAT


you would end up having to publish ~64x101 data in the witness, so only
6464 total (and about 24x101 = 2424 and change for the script)

Making the script smaller also means that choice of hash160/sha256 doesn't
change script size much, just witness. And the witnesses are free to
provide their own preimages, so it would be OK to use something > 20 bytes,
< 32 for more variable security/length tradeoff.


At the cost of marginally bigger script (by about 6x101 bytes), you can
save 20x101 off the witness stack by making each key H(H(xT) || H(x0)) ||
H(x1). 43x101 + 30x101 = 7373 + change for the final grouping.

witnesses:
<0> 
  <1> 
  <2> 

script:
HASH SWAP
IFDUP
NOTIF# 0 passed in (0)
ROT SWAP CAT HASH
ELSE
<3**n> TOALT
1SUB
IF # 2 passed in (+1)
FROMALT # do nothing
ELSE # 1 passed in (T)
TOALTSTACK CAT HASH FROMALTSTACK SWAP # Swaps H(xT) to back
FROMALT NEGATE # negate
END
FROMALT ADD TOALT # add to accumulator
ENDIF
CAT


--
@JeremyRubin 



On Fri, Jul 9, 2021 at 12:03 PM Ethan Heilman  wrote:

> >Yes, quite neat indeed, too bad Lamport signatures are so huge (a couple
> kilobytes)... blocksize increase *cough*
>
> Couldn't you significantly compress the signatures by using either
> Winternitz OTS or by using OP_CAT to build a merkle tree so that the
> full signature can be derived during script execution from a much
> shorter set of seed values?
>
> On Thu, Jul 8, 2021 at 4:12 AM ZmnSCPxj via bitcoin-dev
>  wrote:
> >
> >
> > Good morning Jeremy,
> >
> > Yes, quite neat indeed, too bad Lamport signatures are so huge (a couple
> kilobytes)... blocksize increase *cough*
> >
> > Since a quantum computer can derive the EC privkey from the EC pubkey
> and this scheme is resistant to that, I think you can use a single
> well-known EC privkey, you just need a unique Lamport keypair for each UTXO
> (uniqueness being mandatory due to Lamport requiring preimage revelation).
> >
> > Regards,
> > ZmnSCPxj
> >
> >
> > > Dear Bitcoin Devs,
> > >
> > > As mentioned previously, OP_CAT (or similar operation) can be used to
> make Bitcoin "quantum safe" by signing an EC signature. This should work in
> both Segwit V0 and Tapscript, although you have to use HASH160 for it to
> fit in Segwit V0.
> > >
> > > See [my blog](https://rubin.io/blog/2021/07/06/quantum-bitcoin/) for
> the specific construction, reproduced below.
> > >
> > > Yet another entry to the "OP_CAT can do that too" list.
> > >
> > > Best,
> > >
> > > Jeremy
> > > -
> > >
> > > I recently published [a blog
> > > post](https://rubin.io/blog/2021/07/02/signing-5-bytes/) about
> signing up to a
> > > 5 byte value using Bitcoin script arithmetic and Lamport signatures.
> > >
> > > By itself, this is neat, but a little limited. What if we could sign
> longer
> > > messages? If we can sign up to 20 bytes, we could sign a HASH160
> digest which
> > > is most likely quantum safe...
> > >
> > > What would it mean if we signed the HASH160 digest of a signature?
> What the
> > > what? Why would we do that?
> > >
> > > Well, as it turns out, even if a quantum computer were able to crack
> ECDSA, it
> > > would yield revealing the private key but not the ability to malleate
> the
> > > content of what was actually signed.  I asked my good friend and
> cryptographer
> > > [Madars Virza](https://madars.org/) if my intuition was correct,

Re: [bitcoin-dev] OP_CAT Makes Bitcoin Quantum Secure [was CheckSigFromStack for Arithmetic Values]

[ZmnSCPxj via bitcoin-dev]

Good morning Ethan,

> > Yes, quite neat indeed, too bad Lamport signatures are so huge (a couple 
> > kilobytes)... blocksize increase cough
>
> Couldn't you significantly compress the signatures by using either
> Winternitz OTS or by using OP_CAT to build a merkle tree so that the
> full signature can be derived during script execution from a much
> shorter set of seed values?

To implement Winternitz we need some kind of limited-repeat construct, which is 
not available in SCRIPT, but may be emulatable with enough `OP_IF` and sheer 
brute force.
But what you gain in smaller signatures, you lose in a more complex and longer 
SCRIPT, and there are limits to SCRIPT size (in order to limit the processing 
done in each node).

Merkle signatures trade off shorter pubkeys for longer signatures (signatures 
need to provide the hash of the *other* preimage you are not revealing), but in 
the modern post-SegWit Bitcoin context both pubkeys and signatures are stored 
in the witness area, which have the same weight, thus it is actually a loss 
compared to Lamport.


So yes, maybe Winternitz (could be a replacement for the "trinary" Jeremy 
refers to), Merkle not so much.

Regards,
ZmnSCPxj

> On Thu, Jul 8, 2021 at 4:12 AM ZmnSCPxj via bitcoin-dev
> bitcoin-dev@lists.linuxfoundation.org wrote:
>
> > Good morning Jeremy,
> > Yes, quite neat indeed, too bad Lamport signatures are so huge (a couple 
> > kilobytes)... blocksize increase cough
> > Since a quantum computer can derive the EC privkey from the EC pubkey and 
> > this scheme is resistant to that, I think you can use a single well-known 
> > EC privkey, you just need a unique Lamport keypair for each UTXO 
> > (uniqueness being mandatory due to Lamport requiring preimage revelation).
> > Regards,
> > ZmnSCPxj
> >
> > > Dear Bitcoin Devs,
> > > As mentioned previously, OP_CAT (or similar operation) can be used to 
> > > make Bitcoin "quantum safe" by signing an EC signature. This should work 
> > > in both Segwit V0 and Tapscript, although you have to use HASH160 for it 
> > > to fit in Segwit V0.
> > > See my blog for the specific construction, reproduced below.
> > > Yet another entry to the "OP_CAT can do that too" list.
> > > Best,
> > >
> > > Jeremy
> > >
> > > ---
> > >
> > > I recently published a blogpost about signing up to a5 byte value using 
> > > Bitcoin script arithmetic and Lamport signatures.
> > > By itself, this is neat, but a little limited. What if we could sign 
> > > longer
> > > messages? If we can sign up to 20 bytes, we could sign a HASH160 digest 
> > > which
> > > is most likely quantum safe...
> > > What would it mean if we signed the HASH160 digest of a signature? What 
> > > the
> > > what? Why would we do that?
> > > Well, as it turns out, even if a quantum computer were able to crack 
> > > ECDSA, it
> > > would yield revealing the private key but not the ability to malleate the
> > > content of what was actually signed. I asked my good friend and 
> > > cryptographer
> > > Madars Virza if my intuition was correct, and he
> > > confirmed that it should be sufficient, but it's definitely worth closer
> > > analysis before relying on this. While the ECDSA signature can be 
> > > malleated to a
> > > different, negative form, if the signature is otherwise made immalleable 
> > > there
> > > should only be one value the commitment can be opened to.
> > > If we required the ECDSA signature be signed with a quantum proof 
> > > signature
> > > algorithm, then we'd have a quantum proof Bitcoin! And the 5 byte signing 
> > > scheme
> > > we discussed previously is a Lamport signature, which is quantum secure.
> > > Unfortunately, we need at least 20 contiguous bytes... so we need some 
> > > sort of
> > > OP\_CAT like operation.
> > > OP\_CAT can't be directly soft forked to Segwit v0 because it modifies the
> > > stack, so instead we'll (for simplicity) also show how to use a new 
> > > opcode that
> > > uses verify semantics, OP\_SUBSTRINGEQUALVERIFY that checks a splice of a 
> > > string
> > > for equality.
> > >
> > > ... FOR j in 0..=5
> > > <0>
> > > ... FOR i in 0..=31
> > > SWAP hash160 DUP  EQUAL IF DROP <2**i> ADD ELSE 
> > >  EQUALVERIFY ENDIF
> > > ... END FOR
> > > TOALTSTACK
> > > ... END FOR
> > >
> > > DUP HASH160
> > >
> > > ... IF CAT AVAILABLE
> > > FROMALTSTACK
> > > ... FOR j in 0..=5
> > > FROMALTSTACK
> > > CAT
> > > ... END FOR
> > > EQUALVERIFY
> > > ... ELSE SUBSTRINGEQUALVERIFY AVAILABLE
> > > ... FOR j in 0..=5
> > > FROMALTSTACK <0+j*4> <4+j*4> SUBSTRINGEQUALVERIFY DROP DROP 
> > > DROP
> > > ...  END FOR
> > > DROP
> > > ... END IF
> > >
> > >  CHECKSIG
> > >
> > >
> > > That's a long script... but will it fit? We need to verify 20 bytes of 
> > > message
> > > each bit takes around 10 bytes script, an average of 3.375 bytes per 
> > > numbe

Re: [bitcoin-dev] Proof of reserves - recording

[Billy Tetrud via bitcoin-dev]

>  there is an unsupportable leap being made here

You think that because you're misinterpreting me. I'm in no way claiming
that any solvent company can prove it, I'm simply claiming that any company
can prove that they have bitcoin reserves to cover bitcoins promised as
account balances.

> Banks (lending institutions) do not operate under any such pretense

You seem to be saying that banks are under no legal obligation to serve
cash on demand to customers. While you might be right, again you're
misinterpreting me. Banks do in fact make claims to their customers that
they'll be able to get cash out of their account on demand. They're called
demand deposit accounts for a reason. And certainly customers expect to be
able to withdraw their cash on demand.

> With a 100% of investment cash hoard, there is zero lending and zero
return

I did say "pretend" did I not?

> “relate to” is a far cry from 100% “reserve”

Indeed. Again, you seem to be misunderstanding me. You're putting the words
"100% reserve" in my mouth, when I never said any such thing. Proof of
80%/50%/20% reserves is still useful if that's the clear expectation for
the customer/client.

> Nonsense is English for “doesn’t make sense”

Literally, sure. But in actual use it carries a dismissive and rude
connotation.


On Fri, Jul 9, 2021 at 7:55 AM Eric Voskuil  wrote:

>
> > On Jul 7, 2021, at 01:20, Billy Tetrud via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > But people can certainly pull their money out of companies that can't
> show solvency.
>
> As I pointed out previously there is an unsupportable leap being made here
> between a vault (money warehouse) and any company (including a bank).
>
> A company cannot possibly show that it has all of the money that every
> person has invested into it. At times a solvent company may even have zero
> cash. It is also not possible for a company provide cryptographic proof of
> its many necessarily non-crypto assets and liabilities. What is presumed
> here is a community-verified sort of crypto balance sheet, with no
> considerations of risk - a central aspect of business.
>
> As I said, if you want a vault, you can just use your own wallet. Solvency
> does not in any way imply 100% cash balance of the amounts invested.
> Raising money under such terms is pointless for both company and investors
> (the owners of the company).
>
> > > Nonsense, any business can fail, regardless of temporal cash reserves.
> >
> > I agree that any business can fail. But a bank that pretends it can
> serve cash on demand is not a normal business,
>
> Banks (lending institutions) do not operate under any such pretense. US
> banks require 7 day time deposits for all interest bearing accounts (read
> your depositor agreement), and it should be clear that your uninsured
> balance is at risk. Banks are investment funds, not money warehouses (in
> Rothbard’s terminology).
>
> With a 100% of investment cash hoard, there is zero lending and zero
> return. This is true for all business.
>
> > and cash reserves absolutely relate to their ability to survive as a
> bank.
>
> “relate to” is a far cry from 100% “reserve”. At 100% reserve an
> investment fund would most certainly fail. At 20% it would fail. Money
> markets (banks without a reserve requirement) don’t break the buck, compete
> effectively with banks with reserve requirements (required by the taxpayer
> who is insuring deposits and providing discount credit), and maintain
> around 10% reserve. This is consistent with a world of people with time
> preference that creates around a 10% interest rate (return on investment).
>
> > Its honestly confusing to me how you could think otherwise.
>
> It’s confusing to me how anyone would put money into a business and expect
> (even want) it to sit there.
>
> > Also, calling my thoughts "nonsense" is rude, please check yourself,
> Eric.
>
> Check myself? Nonsense is English for “doesn’t make sense”. It’s not an
> insult.
>
> e
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proof of reserves - recording

[Billy Tetrud via bitcoin-dev]

@Voskuil
> You can prove that in your own wallet. All other scenarios imply lending
(which is what is implied by “reserve”) and lending cannot be 100% reserve.

You're using terms in non-standard ways. Putting money into a bank is not
considered "lending" to the bank. You may make a case that you're lending
to a bank, and that they legally owe you repayment of that money on demand
limited by the terms you mentioned. But regardless of a case that can be
made there, pretty much no one considers that "lending". Since you you like
defining things legally, depositing money in a bank is legally not defined
as lending to the bank.

So no, all other scenarios do not imply lending. You can have your coins in
custody with someone else, and that someone else can keep 100% reserves if
they choose (or agreed to) and can prove it to you via the method I
described or the methods others have linked to.

> They are time deposits, read your bank agreement.

You are not correct
.
Another source

if you don't believe me. The only way you would be correct is if banks were
committing fraud and calling something a "savings account" when it isn't in
fact a savings account.

> money markets have had no reserve requirement and have a nearly spotless
record of satisfying their obligations.

Lol, money markets are so new that they've had no opportunity to show their
true risk. In the finance world, things work fine for a long time until
they fail spectacularly, losing more than the gain they made in the first
place. This is a regular occurence. Its the reason bitcoin was created.

> Irrelevant.

It is certainly not irrelevant. People have been lead to believe that they
can withdraw their money from their accounts. People expect this. Banks are
doing nothing to educate people on the limitations of that fact. PoR would
give people the ability to see quite accurately how much reserves there are
and can use this knowledge to put pressure on institutions to keep the
reserves those people think they should keep.

> Without 100% “reserve” there is no way to cryptographically demonstrate
“solvency”.

You can show proof that you're 80% solvent, and then claim the other 20% is
in other assets. This is, again, still useful.

>The schemes don’t preclude hacks, insider or otherwise, bankruptcy, or
state seizure, no matter what the reserve

You're right, but that's irrelevant.

But it seems like you're not interested in understanding what I'm saying or
discussing these things honestly. So I'm going to end my conversation with
you here.


On Fri, Jul 9, 2021 at 11:32 AM Eric Voskuil via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> > On Jul 9, 2021, at 10:44, Billy Tetrud  wrote:
> >
> > >  there is an unsupportable leap being made here
> >
> > You think that because you're misinterpreting me. I'm in no way claiming
> that any solvent company can prove it, I'm simply claiming that any company
> can prove that they have bitcoin reserves to cover bitcoins promised as
> account balances.
>
> You can prove that in your own wallet. All other scenarios imply lending
> (which is what is implied by “reserve”) and lending cannot be 100% reserve.
>
> > > Banks (lending institutions) do not operate under any such pretense
> >
> > You seem to be saying that banks are under no legal obligation to serve
> cash on demand to customers. While you might be right,
>
> I am, as banks are lending institutions.
>
> > again you're misinterpreting me. Banks do in fact make claims to their
> customers that they'll be able to get cash out of their account on demand.
>
> Up to the insured limit, in 7 days. This is of course true because the
> taxpayer has insured the bank to that level.
>
> > They're called demand deposit accounts for a reason.
>
> They are time deposits, read your bank agreement. Not that it makes any
> difference. How the contract is satisfied is not a term of the contract,
> just that it is. And as I pointed out, money markets have had no reserve
> requirement and have a nearly spotless record of satisfying their
> obligations.
>
> > And certainly customers expect to be able to withdraw their cash on
> demand.
>
> Irrelevant.
>
> > > With a 100% of investment cash hoard, there is zero lending and zero
> return
> >
> > I did say "pretend" did I not?
>
> See above.
>
> > > “relate to” is a far cry from 100% “reserve”
> >
> > Indeed. Again, you seem to be misunderstanding me. You're putting the
> words "100% reserve" in my mouth, when I never said any such thing. Proof
> of 80%/50%/20% reserves is still useful if that's the clear expectation for
> the customer/client.
>
> Without 100% “reserve” there is no way to cryptographically demo

Re: [bitcoin-dev] OP_CAT Makes Bitcoin Quantum Secure [was CheckSigFromStack for Arithmetic Values]

[Ethan Heilman via bitcoin-dev]

>Yes, quite neat indeed, too bad Lamport signatures are so huge (a couple 
>kilobytes)... blocksize increase *cough*

Couldn't you significantly compress the signatures by using either
Winternitz OTS or by using OP_CAT to build a merkle tree so that the
full signature can be derived during script execution from a much
shorter set of seed values?

On Thu, Jul 8, 2021 at 4:12 AM ZmnSCPxj via bitcoin-dev
 wrote:
>
>
> Good morning Jeremy,
>
> Yes, quite neat indeed, too bad Lamport signatures are so huge (a couple 
> kilobytes)... blocksize increase *cough*
>
> Since a quantum computer can derive the EC privkey from the EC pubkey and 
> this scheme is resistant to that, I think you can use a single well-known EC 
> privkey, you just need a unique Lamport keypair for each UTXO (uniqueness 
> being mandatory due to Lamport requiring preimage revelation).
>
> Regards,
> ZmnSCPxj
>
>
> > Dear Bitcoin Devs,
> >
> > As mentioned previously, OP_CAT (or similar operation) can be used to make 
> > Bitcoin "quantum safe" by signing an EC signature. This should work in both 
> > Segwit V0 and Tapscript, although you have to use HASH160 for it to fit in 
> > Segwit V0.
> >
> > See [my blog](https://rubin.io/blog/2021/07/06/quantum-bitcoin/) for the 
> > specific construction, reproduced below.
> >
> > Yet another entry to the "OP_CAT can do that too" list.
> >
> > Best,
> >
> > Jeremy
> > -
> >
> > I recently published [a blog
> > post](https://rubin.io/blog/2021/07/02/signing-5-bytes/) about signing up 
> > to a
> > 5 byte value using Bitcoin script arithmetic and Lamport signatures.
> >
> > By itself, this is neat, but a little limited. What if we could sign longer
> > messages? If we can sign up to 20 bytes, we could sign a HASH160 digest 
> > which
> > is most likely quantum safe...
> >
> > What would it mean if we signed the HASH160 digest of a signature? What the
> > what? Why would we do that?
> >
> > Well, as it turns out, even if a quantum computer were able to crack ECDSA, 
> > it
> > would yield revealing the private key but not the ability to malleate the
> > content of what was actually signed.  I asked my good friend and 
> > cryptographer
> > [Madars Virza](https://madars.org/) if my intuition was correct, and he
> > confirmed that it should be sufficient, but it's definitely worth closer
> > analysis before relying on this. While the ECDSA signature can be malleated 
> > to a
> > different, negative form, if the signature is otherwise made immalleable 
> > there
> > should only be one value the commitment can be opened to.
> >
> > If we required the ECDSA signature be signed with a quantum proof signature
> > algorithm, then we'd have a quantum proof Bitcoin! And the 5 byte signing 
> > scheme
> > we discussed previously is a Lamport signature, which is quantum secure.
> > Unfortunately, we need at least 20 contiguous bytes... so we need some sort 
> > of
> > OP\_CAT like operation.
> >
> > OP\_CAT can't be directly soft forked to Segwit v0 because it modifies the
> > stack, so instead we'll (for simplicity) also show how to use a new opcode 
> > that
> > uses verify semantics, OP\_SUBSTRINGEQUALVERIFY that checks a splice of a 
> > string
> > for equality.
> >
> > ```
> > ... FOR j in 0..=5
> > <0>
> > ... FOR i in 0..=31
> > SWAP hash160 DUP  EQUAL IF DROP <2**i> ADD ELSE 
> >  EQUALVERIFY ENDIF
> > ... END FOR
> > TOALTSTACK
> > ... END FOR
> >
> > DUP HASH160
> >
> > ... IF CAT AVAILABLE
> > FROMALTSTACK
> > ... FOR j in 0..=5
> > FROMALTSTACK
> > CAT
> > ... END FOR
> > EQUALVERIFY
> > ... ELSE SUBSTRINGEQUALVERIFY AVAILABLE
> > ... FOR j in 0..=5
> > FROMALTSTACK <0+j*4> <4+j*4> SUBSTRINGEQUALVERIFY DROP DROP DROP
> > ...  END FOR
> > DROP
> > ... END IF
> >
> >  CHECKSIG
> > ```
> >
> > That's a long script... but will it fit? We need to verify 20 bytes of 
> > message
> > each bit takes around 10 bytes script, an average of 3.375 bytes per number
> > (counting pushes), and two 21 bytes keys = 55.375 bytes of program space 
> > and 21
> > bytes of witness element per bit.
> >
> > It fits! `20*8*55.375 = 8860`, which leaves 1140 bytes less than the limit 
> > for
> > the rest of the logic, which is plenty (around 15-40 bytes required for the 
> > rest
> > of the logic, leaving 1100 free for custom signature checking). The stack 
> > size
> > is 160 elements for the hash gadget, 3360 bytes.
> >
> > This can probably be made a bit more efficient by expanding to a ternary
> > representation.
> >
> > ```
> > SWAP hash160 DUP  EQUAL  IF DROP  ELSE <3**i> SWAP DUP 
> >  EQUAL IF DROP SUB ELSE  EQUALVERIFY ADD  ENDIF 
> > ENDIF
> > ```
> >
> > This should bring it up to roughly 85 bytes per trit, and there should be 
> > 101
> > trits (`log(2**160)/log(3) == 100.94`), so about 8560 bytes... a bit 
> > cheaper!
> > But the witness stack is "only" `2121` bytes...
> >
> > As a homework exercise, maybe someone can prove the

Re: [bitcoin-dev] Proof of reserves - recording

[Eric Voskuil via bitcoin-dev]

> On Jul 9, 2021, at 10:44, Billy Tetrud  wrote:
> 
> >  there is an unsupportable leap being made here
> 
> You think that because you're misinterpreting me. I'm in no way claiming that 
> any solvent company can prove it, I'm simply claiming that any company can 
> prove that they have bitcoin reserves to cover bitcoins promised as account 
> balances. 

You can prove that in your own wallet. All other scenarios imply lending (which 
is what is implied by “reserve”) and lending cannot be 100% reserve.

> > Banks (lending institutions) do not operate under any such pretense
> 
> You seem to be saying that banks are under no legal obligation to serve cash 
> on demand to customers. While you might be right,

I am, as banks are lending institutions.

> again you're misinterpreting me. Banks do in fact make claims to their 
> customers that they'll be able to get cash out of their account on demand.

Up to the insured limit, in 7 days. This is of course true because the taxpayer 
has insured the bank to that level.

> They're called demand deposit accounts for a reason.

They are time deposits, read your bank agreement. Not that it makes any 
difference. How the contract is satisfied is not a term of the contract, just 
that it is. And as I pointed out, money markets have had no reserve requirement 
and have a nearly spotless record of satisfying their obligations.

> And certainly customers expect to be able to withdraw their cash on demand. 

Irrelevant.

> > With a 100% of investment cash hoard, there is zero lending and zero return
> 
> I did say "pretend" did I not?

See above.

> > “relate to” is a far cry from 100% “reserve”
> 
> Indeed. Again, you seem to be misunderstanding me. You're putting the words 
> "100% reserve" in my mouth, when I never said any such thing. Proof of 
> 80%/50%/20% reserves is still useful if that's the clear expectation for the 
> customer/client.

Without 100% “reserve” there is no way to cryptographically demonstrate 
“solvency”. And even with that, investors would have to accept the promise that 
there are no other liabilities.

The schemes don’t preclude hacks, insider or otherwise, bankruptcy, or state 
seizure, no matter what the reserve.

It’s information, sure, but it’s not what people seem to think. If one wants 
full reserve banking, use a wallet. If one wants to invest, the money will be 
spent - that’s why it was raised. There can be no covenant placed on it that 
will ensure it’s return.

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

Re: [bitcoin-dev] Proof of reserves - recording

[Eric Voskuil via bitcoin-dev]

> On Jul 7, 2021, at 01:20, Billy Tetrud via bitcoin-dev 
>  wrote:

> But people can certainly pull their money out of companies that can't show 
> solvency. 

As I pointed out previously there is an unsupportable leap being made here 
between a vault (money warehouse) and any company (including a bank).

A company cannot possibly show that it has all of the money that every person 
has invested into it. At times a solvent company may even have zero cash. It is 
also not possible for a company provide cryptographic proof of its many 
necessarily non-crypto assets and liabilities. What is presumed here is a 
community-verified sort of crypto balance sheet, with no considerations of risk 
- a central aspect of business.

As I said, if you want a vault, you can just use your own wallet. Solvency does 
not in any way imply 100% cash balance of the amounts invested. Raising money 
under such terms is pointless for both company and investors (the owners of the 
company).

> > Nonsense, any business can fail, regardless of temporal cash reserves.
> 
> I agree that any business can fail. But a bank that pretends it can serve 
> cash on demand is not a normal business,

Banks (lending institutions) do not operate under any such pretense. US banks 
require 7 day time deposits for all interest bearing accounts (read your 
depositor agreement), and it should be clear that your uninsured balance is at 
risk. Banks are investment funds, not money warehouses (in Rothbard’s 
terminology).

With a 100% of investment cash hoard, there is zero lending and zero return. 
This is true for all business.

> and cash reserves absolutely relate to their ability to survive as a bank.

“relate to” is a far cry from 100% “reserve”. At 100% reserve an investment 
fund would most certainly fail. At 20% it would fail. Money markets (banks 
without a reserve requirement) don’t break the buck, compete effectively with 
banks with reserve requirements (required by the taxpayer who is insuring 
deposits and providing discount credit), and maintain around 10% reserve. This 
is consistent with a world of people with time preference that creates around a 
10% interest rate (return on investment).

> Its honestly confusing to me how you could think otherwise.

It’s confusing to me how anyone would put money into a business and expect 
(even want) it to sit there.

> Also, calling my thoughts "nonsense" is rude, please check yourself, Eric. 

Check myself? Nonsense is English for “doesn’t make sense”. It’s not an insult.

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

Re: [bitcoin-dev] A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent

[Antoine Riard via bitcoin-dev]

On Thu, May 27, 2021 at 04:14:13PM -0400, Antoine Riard via bitcoin-dev
wrote:
> This overhead could be smoothed even further in the future with more
advanced
> sighash malleability flags like SIGHASH_IOMAP, allowing transaction
signers to
> commit to a map of inputs/outputs [2]. In the context of input-based, the
> overflowed fee value could be redirected to an outgoing output.

> Input-based (SIGHASH_ANYPREVOUT+SIGHASH_IOMAP): Multiple chains of
transactions
> might be aggregated together *non-interactively*. One bumping input and
> outgoing output can be attached to the aggregated root.

> [2] https://bitcointalk.org/index.php?topic=252960.0

> I haven't seen any recent specs for "IOMAP", but there are a few things
> that have bugged me about them in the past:

TBH, I don't think we have been further with Darosior than comparing the
compression schemes relevant for the bitfield :)

Thanks to start the hard grinding work!

>  (1) allowing partially overlapping sets of outputs could allow "theft",
>  eg if I give you a signature "you can spend A+B as long as I get X"
>  and "you can spend A+C as long as I get X", you could combine them
>  to spend A+B+C instead but still only give me 1 X.

Yes I think there is an even more unsafe case than described. A transaction
third-party knowledgeable about the partial sets could combine them, then
attach an additional siphoning output Y. E.g, if {A=50, B=50, C=50} and
X=100 the third-party could attach output Y=50 ?

Though I believe the validity of those thefts are a function of further
specification of the transaction digest coverage, as you might have a
malleability scheme where B or C's signatures hash are implicitly
committing to subset inputs order. If you have `H_prevouts(A || B)` and
`H_prevouts(A || C)`, an attacker wouldn't be able to satisfy both B and C
scripts in the same transaction ?

One mitigation which was mentioned in previous pinning discussion was to
add a per-participant finalizing key to A's script and thus lockdown
transaction template at broadcast. I don't think it works here as you can't
assume that your counterparties, from different protocol sessions, won't
collude together to combine their finalizing signatures and achieve a spend
replay across sessions ?

That said, I'm not even sure we should disallow partially overlapping sets
of outputs at the consensus-level, one could imagine a crowdfunding
application where you delegate A+B and A+C to different parties, and you
implicitly allow them to cooperate as long as they fulfill X's output value
?

>  (2) a range specification or a whole bitfield is a lot heavier than an
>  extra bit to add to the sighash

Yes, one quick optimization in case of far-depth output committed in the
bitfield could be to have a few initial bits serving as vectors to blank
out unused bitfield spaces. Though I concede a new sighash bits arithmetic
might be too fancy for consensus-code.


>  (3) this lets you specify lots of different ways of hashing the
>  outputs, which then can't be cached, so you get kind-of quadratic
>  behaviour -- O(n^2/8) where n/2 is the size of the inputs, which
>  gives you the number of signatures, and n/2 is also the size of the
>  outputs, so n/4 is a different half of the output selected for each
>  signature in the input.

If you assume n size of transaction data, and that each signature hash is
committing to inputs + half of outputs, yes I think it's even worst kind-of
quadratic, like O(3n^2/4) ? And you might even worsen the hashing in
function of flexibility allowed, like still committing to the whole
transaction size but a different combination order of outputs selected for
each signature.

But under the "don't bring me problems, bring me solutions" banner, here's
an idea.

> The easy way to avoid O(n^2) behaviour in (3) is to disallow partial
> overlaps. So let's treat the tx as being distinct bundles of x-inputs
> and y-outputs, and we'll use the annex for grouping, since that is
> committed to by singatures. Call the annex field "sig_group_count".

> When processing inputs, setup a new state pair, (start, end), initially
> (0,0).
>
> When evaluating an input, lookup sig_group_count. If it's not present,
> then set start := end. If it's present and 0, leave start and end
> unchanged. Otherwise, if it's present and greather than 0, set
> start := end, and then set end := start + sig_group_count.

IIUC the design rationale, the "sig_group_count" lockdowns the hashing of
outputs for a given input, thus allowing midstate reuse across signatures
input.

> Introduce a new SIGHASH_GROUP flag, as an alternative to ALL/SINGLE/NONE,
> that commits to each output i, start <= i < end. If start==end or end >
> num_outputs, signature is invalid.
>
> That means each output in a tx could be hashed three times instead of
> twice (once for its particular group, as well as once for SIGHASH_ALL
> and once for SIGHASH_SINGLE), and I think would let you combine x-