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
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
>
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
> 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.
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
>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
>> 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
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
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
> 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
@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
>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
> 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
> 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
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
15 matches
Mail list logo
