Hi Burak,
Thanks for the interesting Ark proposal.
>From my understanding the protocol is played between 3 entities: the
sender, the receiver and the ASP and you have 3 types of transactions:
- the pool_tx
- the ATLC-connection_tx
- the ATLC-refund_tx
The pool_tx spends an on-chain funding input
Hi Peter,
Re: https://github.com/bitcoin/bitcoin/pull/28130
I have a few questions about your proposal and its impact on full node
operators:
1. With your proposed policy change removing the OP_RETURN output count and
data size limits, is there ever a case where using OP_RETURN to embed data
On July 30, 2023 11:37:49 AM HST, Salvatore Ingala via bitcoin-dev
>I have put together a first complete proposal for the core opcodes of
>MATT [1][2].
>The changes make the opcode functionally complete, and the
>implementation is revised and improved.
> [...]
>[1] - https://merkle.fun/
>[2] -
>
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 | 1
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 their own BIP and
be a standard that can work for xpubs, static paymen
Why the 180 year limit? imho should plan for longer.
On Fri, Aug 4, 2023 at 10:41 AM Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> tl;dr: Wallets don't last forever. They are often compromised or lost. When
> this happens, the addresses generated from those wallets
