Question for OG bitcoin API designers please.
If you were to see the following function
`is_segwit()`
would you assume it returns `true` or `false` for a p2tr transaction?
Currently we (rust-bitcoin) are being liberal with the use of `v0` but
its a pretty ugly. Is there an official, or wid
On Sun, Aug 06, 2023 at 02:20:06PM +, josibake wrote:
> Hi Peter,
>
> Thanks for the feedback! As you mentioned, this is a more general problem in
> Bitcoin and not specific to BIP352. Therefore, if expiration dates are indeed
> something we want, they should be proposed and discussed as the
Sorry for yet another message but:
It just occurred to me that while timing correlation itself might not be much
(in usual circumstances, there are tons of other transactions), it's, as usual
with metadata, the intersection of more than one thing that could hurt: I know
when the tx happens (say
Sorry forgot to include list on this:
> Hi Dan,
> Thanks for this! I look forward to reading it in detail, these ideas are for
> sure very interesting.
>
> I wanted to immediately "nit" a point I saw as I was reading:
>
> > Because BIP 78 messages are neither authenticated nor encrypted a malic
Hi Dan,
A couple more more thoughts:
> Out of band, the receiver of the payment, shares a bitcoin URI with the
> sender including a pj= query parameter describing the relay
> subdirectory endpoint and psk= parameter with base64 encoded
> 256-bit secret key.
You're sending the symmetric secret
HI Lloyd,
Yes, the blind signatures are for bitcoin transactions (these are
timelocked 'backup txs' if the server disappears). This is not standard
'Schnorr blind signature' (like
https://suredbits.com/schnorr-applications-blind-signatures/) but a 2-of-2
MuSig where two keys are required to genera
