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
Good morning Russell,
> Hi ZmnSCPxj,
>
> I don't believe we need to ban Turing completeness for the sake of banning
> Turing completeness.
Well I believe we should ban partial Turing-completeness, but allow total
Turing-completeness.
I just think that unlimited recursive covenants (with or
I don't think Elements engineering decisions or management timelines should
have any bearing on what Bitcoin adopts, beyond learning what
works/doesn't. Same as litecoin, dogecoin, or bitcoin cash :)
With my understanding of elements it makes sense that you wouldn't want to
break compatibility
> you should check out some of the earlier work done here:
>
> https://github.com/olalonde/proof-of-solvency#assets-proofNothing in this
Nothing here refutes what I have said. Furthermore it relies on the
assumption that all assets and liabilities are provable. This is clearly
prohibitive.
>
heh -- I pointed out these evil multisig covenants in 2015 :)
https://medium.com/@jeremyrubin/regulating-bitcoin-by-mining-the-regulator-miner-attack-c8fd51185b78
I'm relatively unconcerned by it except to the extent that mining
centralizes to the point of censoring other traffic.
Overall, I
you should check out some of the earlier work done here:
https://github.com/olalonde/proof-of-solvency#assets-proof
to be honest, if any exchange supported that proof, it would be more
than enough.
there's really no way to prevent a smash-and-grab, but this does
prevent a slow-leak
On Mon,
If the main outstanding issue is whether to split R or S, I think as far as
Elements goes, I am inclined to go with the CAT option regardless of
whether Bitcoin chooses to split R/S or not (not that I'm necessarily a
decision maker here).
The issue here is that (a) Elements already has CAT, and
Re-threading Sanket's comment on split R value:
I also am in general support of the `OP_CHECKSIGFROMSTACK` opcode. We would
> need to update the suggestion to BIP340, and add it to sigops budget. I
> have no strong preference for splitting R and s values or variable-length
> messages.
>
Back to
On Tue, Jul 6, 2021 at 2:26 AM Billy Tetrud wrote:
> > when people are talking about enabling covenants, we are talking about
> whether OP_CAT should be allowed or not
>
> Are they? Are you implying that anything that enables covenants is
> equivalent to enabling OP_CAT? Generally when I think
After some brainstorming about the possible drawbacks of enabling
covenants, I have also slowly become more comfortable with the idea of
"unlimited" covenants. AJs example clearly shows that _all_ possible
"misuses" of covenants are already possible by Multi-Sig today, so it's not
a new vector
@ZmnSCPxj
> a thief (or "thief") who has gotten a copy of the key can sign a
transaction that spends it, one second after the proof-of-reserves is made.
Sure, but anyone can easily see that transaction happen and can discount
that part of the attestation. The same isn't true on lightning.
>
> when people are talking about enabling covenants, we are talking about
whether OP_CAT should be allowed or not
Are they? Are you implying that anything that enables covenants is
equivalent to enabling OP_CAT? Generally when I think about enabling
covenants, I'm thinking more about OP_CTV (or
@ ZmnSCPxj, Good Evening
> The two participants in the channel can sign a plaintext containing
their node pubkeys and how much each owns
Sure, but even if both participants in the channel sign a correct statement
of truth, one of the participants can send funds out in the next second,
> @Eric
> Auditability Fallacy
>
> > A solvency audit requires simultaneous (atomic) proof of both the full
> > amount of the asset held by a custodian and the securities issued against
> > it.
>
> > in the case where the security is issued on a distinct public chain the
> > atomicity
14 matches
Mail list logo
