Hi Peter,
On 2024-01-24 (Wed) at 19:31:07 +, Peter Todd via bitcoin-dev wrote:
> It is
> expected that CTV would be usually used with anchor outputs to pay fees; by
> creating an input of the correct size in a separate transaction and including
> it in the CTV-committed transaction; or
Hi Seedhammer,
I think the goal of such a format should be that it is already a valid
PSBT, or can be trivially converted into one. Ideally, a coordinating
device can load the standardized descriptor file, add inputs (PSBTv2) or
unsigned TX (PSBTv1), and send it to compatible signing devices
On 2023-10-20 (Fri) at 14:10:37 +1030, Rusty Russell via bitcoin-dev wrote:
> I've done an exploration of what would be required (given
> OP_TX/OP_TXHASH or equivalent way of pushing a scriptPubkey on the
> stack) to usefully validate Taproot outputs in Bitcoin Script. Such
>
> > * If the top item on the stack is not a minimally encoded `OP_0`, `OP_1`,
> or
> `OP_2`; succeed immediately[^2].
>
> I presume this was supposed to go to OP_4 now.
Fixed, thanks!
> > ### How does the efficiency compare to [bip118][]?
>
> Just noting BIP118 also allows pubkey of "1" to
Quick update to the proposal thanks to James O'Beirne: CTV is 2-bytes
less expensive than I thought when used alone. I thought that script
success required exactly OP_TRUE not just a CastToBool()=true value on
the stack.
This means that my proposal is 2 weight units (0.5vBytes) larger than
CTV
Hi list,
https://gist.github.com/reardencode/2aa98700b720174598d21989dd46e781
I'm seeking feedback on this proposal to provide the functionality
requested by those advocating for bip118 and bip119 in a combined way
that retains the low risk associated with each of those separate
proposals. At
On 2023-08-05 (Sat) at 14:06:10 +, Peter Todd via bitcoin-dev wrote:
> > bytes | prefix | usable bits | granularity | max expiration
> > --||-|-|---
> > 1 | 0b0| 7 | year| 128 years
> > 2 | 0b10 |
I agree. Non-expiring addresses are a significant risk to bitcoin users.
On 2023-08-04 (Fri) at 17:39:03 +, Peter Todd via bitcoin-dev wrote:
> Fixing this is easy: add a 3 byte field to silent payments addresses, encoding
> the expiration date in terms of days after some epoch. 2^24 days is
Hi Gents,
> > I don't think replacing the internal-public-key makes sense -- if it
> was immediately spendable via the keypath before there's no reason for
> it not to be immediately spendable now.
>
> Slavishly following the current proposal was the idea to make sure all
> functionality was
On 2022-08-24 (Wed) at 11:18:43 +0200, Craig Raw via bitcoin-dev wrote:
> I would like to propose a BIP that specifies a format for the export and
> import of labels from a wallet. While transferring access to funds across
> wallet applications has been made simple through standards such as BIP39,
Hi Rusty,
Thanks for this. Seems like a productive direction to explore.
To me, one of the biggest limitations of CTV is that the script is
specific to the amount of the input being spent. OP_TX makes it
possible, although clumsy, to emulate OP_IN_OUT_AMOUNT, which could be
combined with CTV
Hi Laolu,
> Finally, can you elaborate a bit on this fragment of the BIP that
describes
> a "short cut" when a specific signers is meant to send their nonces last:
>
> > Second, if there is a unique signer who is supposed to send the pubnonce
> > last, it is possible to modify nonce generation
12 matches
Mail list logo
