[bitcoin-dev] [Bitcoin Advent Calendar]: Congestion Control

2021-12-09 Thread Jeremy via bitcoin-dev
Today's post is a follow up to some older content about congestion control & CTV. It's written (as with the rest of the series) to be a bit more approachable than technical, but there are code samples in Sapio of constructing a payout tree. today's post: https://rubin.io/bitcoin/2021/12/09/advent

Re: [bitcoin-dev] A fee-bumping model

2021-12-09 Thread Peter Todd via bitcoin-dev
On Mon, Nov 29, 2021 at 02:27:23PM +, darosior via bitcoin-dev wrote: > ## 2. Problem statement > > For any delegated vault, ensure the confirmation of a Cancel transaction in a > configured number of > blocks at any point. In so doing, minimize the overpayments and the UTxO set > footprint.

Re: [bitcoin-dev] [Lightning-dev] Sending OP_RETURN via Bitcoin Lightning

2021-12-09 Thread Peter Todd via bitcoin-dev
On Thu, Dec 09, 2021 at 07:12:45AM -0500, Alex Schoof wrote: > The multisig scheme is interesting. From my understanding of Single Use > Seals, since seal n commits to seal n+1, for the on-chain aggregation seals > you would want to pick some common aggregation service provider ahead of > time and

Re: [bitcoin-dev] [Lightning-dev] Sending OP_RETURN via Bitcoin Lightning

2021-12-09 Thread Alex Schoof via bitcoin-dev
The multisig scheme is interesting. From my understanding of Single Use Seals, since seal n commits to seal n+1, for the on-chain aggregation seals you would want to pick some common aggregation service provider ahead of time and if that provider disappears, you’re stuck and cant close the next sea

Re: [bitcoin-dev] [Lightning-dev] Sending OP_RETURN via Bitcoin Lightning

2021-12-09 Thread Peter Todd via bitcoin-dev
On Thu, Dec 09, 2021 at 09:49:11AM +, Christian Moss wrote: > p...@petertodd.org, so single use seals require an onchain transaction to > post the proof of publication to the ledger (assuming bitcoin is used as > the ledger) when an asset is transferred, but it can scale because you can > batch

Re: [bitcoin-dev] [Lightning-dev] Sending OP_RETURN via Bitcoin Lightning

2021-12-09 Thread Christian Moss via bitcoin-dev
p...@petertodd.org, so single use seals require an onchain transaction to post the proof of publication to the ledger (assuming bitcoin is used as the ledger) when an asset is transferred, but it can scale because you can batch many proofs (transfer of ownerships) into a merkle tree and just add th

Re: [bitcoin-dev] A fee-bumping model

2021-12-09 Thread Antoine Riard via bitcoin-dev
Hi Gloria, For LN, I think 3 tower rewards models have been discussed : per-penalty on-chain bounty/per-job micropayment/customer subscription. If curious, see the wip specification : https://github.com/sr-gi/bolt13/blob/master/13-watchtowers.md > - Do we expect watchtowers tracking multiple vaul

Re: [bitcoin-dev] [Lightning-dev] Take 2: Removing the Dust Limit

2021-12-09 Thread damian--- via bitcoin-dev
Good Afternoon, 'Avoiding a soft-fork' is a political concession. Consensus is none of that. KING JAMES HRMH Great British Empire Regards, The Australian LORD HIS EXCELLENCY JAMES HRMH (& HMRH) of Hougun Manor & Glencoe & British Empire MR. Damian A. James Williamson Wills et al. Willtech

Re: [bitcoin-dev] A fee-bumping model

2021-12-09 Thread Antoine Riard via bitcoin-dev
Hi Antoine, > It seems to me the only policy-level mitigation for RBF pinning around the "don't decrease the abolute fees of a less-than-a-block mempool" would be to drop the requirement on increasing absolute fees if the mempool is "full enough" (and the feerate increases exponentially, of course

Re: [bitcoin-dev] [Lightning-dev] Sending OP_RETURN via Bitcoin Lightning

2021-12-09 Thread Peter Todd via bitcoin-dev
On Mon, Dec 06, 2021 at 04:35:19PM +, Christian Moss via bitcoin-dev wrote: > As far as I understand it, RGB doesn't scale NFTs as each > transaction to transfer ownership of an NFT would require an onchain > transaction RGB intends to scale NFTs and similar things in the future via scalable s