On Tue, Jan 30, 2024 at 05:17:04AM +, ZmnSCPxj via bitcoin-dev wrote:
>
> > I should note that under Decker-Russell-Osuntokun the expectation is that
> > both counterparties hold the same offchain transactions (hence why it is
> > sometimes called "LN-symmetry").
> > However, there are two w
On Tue, Jan 30, 2024 at 05:17:04AM +, ZmnSCPxj via bitcoin-dev wrote:
>
> > I should note that under Decker-Russell-Osuntokun the expectation is that
> > both counterparties hold the same offchain transactions (hence why it is
> > sometimes called "LN-symmetry").
> > However, there are two w
On Thu, Jan 18, 2024 at 05:41:14AM -1000, David A. Harding via bitcoin-dev
wrote:
> Question: is there a recommended way to produce a shorter identifier for
> inline use in reading material? For example, for proposal
> BIN-2024-0001-000, I'm thinking:
>
> - BIN24-1 (references whatever the curre
Hi all,
Just under three years ago there was some discussion about the BIPs repo,
with the result that Kalle became a BIPs editor in addition to Luke, eg:
* https://gnusha.org/bitcoin-core-dev/2021-04-22.log
*
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018859.html
It r
On Sat, Dec 30, 2023 at 01:54:04PM +, Michael Folkson via bitcoin-dev wrote:
> > > But "target fixation" [0] is a thing too: maybe "CTV" (and/or "APO") were
> > > just a bad approach from the start.
> It is hard to discuss APO in a vacuum when this is going on the background
> but I'm interes
Huh, this list is still active?
On Fri, Dec 22, 2023 at 10:34:52PM +, alicexbt via bitcoin-dev wrote:
> I think CTV is not ready for activation yet. Although I want it to be
> activated and use payment pools, we still have some work to do and AJ is
> correct that we need to build more apps t
On Sat, Feb 04, 2023 at 08:38:54PM +1000, Anthony Towns via bitcoin-dev wrote:
> > AJ Towns writes:
> > > I think, however, that you can move inscriptions entirely off-chain. I
> > > wrote a little on this idea on twitter already [1], but after a bit more
> > > tho
Hi all,
It's been mentioned on bitcoin-dev [0] that linuxfoundation is apparently
going to cease hosting mailing lists in the next couple of months.
[0]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-November/022134.html
Anyway, I know some folks have already seen it, but I've bee
On Tue, Nov 07, 2023 at 09:37:22AM -0600, Bryan Bishop via bitcoin-dev wrote:
> Web forums are an interesting option, but often don't have good email user
> integration.
> What about bitcointalk.org or delvingbitcoin.org?
delvingbitcoin.org is something I setup; it's a self-hosted discourse
insta
On Sat, Oct 28, 2023 at 03:19:30PM +1030, Rusty Russell via bitcoin-dev wrote:
[Quoted text has been reordered]
> > I think there's two reasons to think about this approach:
> > (a) we want to do vault operations specifically,
> I'm interested in vaults because they're a concrete example I can
On Sat, Oct 21, 2023 at 01:08:03AM -0400, Ethan Heilman via bitcoin-dev wrote:
> We've posted a draft BIP to propose enabling OP_CAT as Tapscript opcode.
> https://github.com/EthanHeilman/op_cat_draft/blob/main/cat.mediawiki
If you're interested in making this available via inquisition, here's
a s
On Fri, Oct 20, 2023 at 02:10:37PM +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
> functional
On Mon, Oct 23, 2023 at 12:43:10PM +1030, Rusty Russell via bitcoin-dev wrote:
> 2. Was there a concrete rationale for maintaining 520 bytes?
Without a limit of 520 bytes, then you can construct a script:
CHECKSIGVERIFY
{DUP CAT}x10
(we know have a string that is the second witness
On Wed, Oct 11, 2023 at 11:59:16PM +, Andrew Chow via bitcoin-dev wrote:
> On 10/11/2023 07:47 PM, Anthony Towns wrote:
> > On Tue, Oct 10, 2023 at 10:28:37PM +, Andrew Chow via bitcoin-dev wrote:
> >> I've written up a BIP draft for MuSig2 PSBT fields. It can
On Tue, Oct 10, 2023 at 10:28:37PM +, Andrew Chow via bitcoin-dev wrote:
> I've written up a BIP draft for MuSig2 PSBT fields. It can be viewed at
> https://github.com/achow101/bips/blob/musig2-psbt/bip-musig2-psbt.mediawiki.
I was hoping to see adaptor signature support in this; but it seems
On Mon, Oct 09, 2023 at 03:46:24PM +0200, Robin Linus via bitcoin-dev wrote:
> Abstract. BitVM is a computing paradigm to express Turing-complete
> Bitcoin contracts.
Please correct me if I'm wrong:
The way I understand this idea is that you take an N-bit claim (in the
given example N=4), and pro
On Fri, Sep 29, 2023 at 03:14:25PM +0200, Johan Torås Halseth via bitcoin-dev
wrote:
> TLDR; Using the proposed opcode OP_CHECKCONTRACTVERIFY and OP_CAT, we
> show to trace execution of the program `multiply` [1] and challenge
> this computation in O(n logn) on-chain transactions:
"O(n log n)" so
On 21 September 2023 11:44:47 am AEST, Lloyd Fournier
wrote:
>Hi AJ,
>
>On Wed, 20 Sept 2023 at 17:19, Anthony Towns wrote:
>
>>
>> I think:
>>
>> https://github.com/BlockstreamResearch/scriptless-scripts/pull/24
>>
>> describes (w/ proof sketc
On Wed, Sep 06, 2023 at 12:14:08PM -0400, Greg Sanders wrote:
> Since taproot channels are deploying Soon(TM), I think it behooves us to
> turn some attention to PTLCs as a practical matter, drilling down a bit
> deeper.
I think a bunch of these depends on who's interested in doing the work
to rol
On Fri, Sep 08, 2023 at 06:54:46PM +, jlspc via Lightning-dev wrote:
> TL;DR
> =
I haven't really digested this, but I think there's a trust vs
capital-efficiency tradeoff here that's worth extracting.
Suppose you have a single UTXO, that's claimable by "B" at time T+L,
but at time T that
On Fri, Sep 08, 2023 at 06:54:46PM +, jlspc via Lightning-dev wrote:
> TL;DR
> =
I haven't really digested this, but I think there's a trust vs
capital-efficiency tradeoff here that's worth extracting.
Suppose you have a single UTXO, that's claimable by "B" at time T+L,
but at time T that
On Mon, Jul 31, 2023 at 02:42:29PM -0400, Clara Shikhelman wrote:
> > A different way of thinking about the monetary approach is in terms of
> > scaling rather than deterrance: that is, try to make the cost that the
> > attacker pays sufficient to scale up your node/the network so that you
> > cont
On Wed, Jul 19, 2023 at 09:56:11AM -0400, Carla Kirk-Cohen wrote:
> Thanks to everyone who traveled far, Wolf for hosting us in style in
> NYC and to Michael Levin for helping out with notes <3
Thanks for the notes!
Couple of comments:
> - What is the “top of mempool” assumption?
FWIW, I think
On Tue, Apr 18, 2023 at 07:17:34PM +, jlspc wrote:
> > One thing that confuses me about the paper is how to think about routing
> > to a "channel" rather than a node -- ie the payment from "E->FG->A" where
> > "FG" isn't "F" or "G", but "both of them".
> Yes, I found it very difficult to think
On Sat, Apr 08, 2023 at 10:26:45PM +, jlspc via Lightning-dev wrote:
> From my perspective, this paper makes two contributions (which, to be fair,
> may only be "interesting" :)
One thing that confuses me about the paper is how to think about routing
to a "channel" rather than a node -- ie th
On Tue, Apr 18, 2023 at 12:40:44PM +, Michael Folkson via bitcoin-dev wrote:
> I do think the perception that it is “the one and only” staging
> ground for consensus changes is dangerous
If you think that about any open source project, the answer is simple:
create your own fork and do a better
On Tue, Apr 04, 2023 at 12:00:32AM +1000, Anthony Towns wrote:
> On Sat, Mar 18, 2023 at 12:41:00AM +, jlspc via Lightning-dev wrote:
> > TL;DR
>
> Step 1: Tunable penalties;
> https://github.com/JohnLaw2/ln-tunable-penalties
>
> https://lists.linuxfoundation.org
On Sat, Mar 18, 2023 at 12:41:00AM +, jlspc via Lightning-dev wrote:
> TL;DR
Even with Harding's optech write ups, and the optech space, I barely
follow all this, so I'm going to try explaining it too as a way of
understanding it myself; hopefully maybe that helps someone. Corrections
welcome,
On Tue, Mar 07, 2023 at 10:45:34PM +1000, Anthony Towns via bitcoin-dev wrote:
> I think there are perhaps four opcodes that are interesting in this class:
>
>idx sPK OP_FORWARD_TARGET
> -- sends the value to a particular output (given by idx), and
> requires tha
On 10 March 2023 4:45:15 am AEST, Greg Sanders via bitcoin-dev
wrote:
>1) OP_FORWARD_SELF is a JET of OP_FLU in the revaulting common case. Maybe
>obvious but I missed this initially and thought it was useful to be pointed
>out.
That was true for TLUV - iirc "FALSE FALSE 0 TLUV" would preserve t
On Mon, Mar 06, 2023 at 10:25:38AM -0500, James O'Beirne via bitcoin-dev wrote:
> What Greg is proposing above is to in essence TLUV-ify this proposal.
FWIW, the way I'm thinking about this is that the "OP_VAULT" concept is
introducing two things:
a) the concept of "forwarding" the input amount
On Wed, Mar 01, 2023 at 10:05:47AM -0500, Greg Sanders via bitcoin-dev wrote:
> Below is a sketch of a replacement for the two opcodes.
I like this! I tried to come up with something along similar lines for
similar reasons, but I think I tried too hard to reduce it to two opcodes
or something and
On Mon, Feb 20, 2023 at 03:22:30PM +, Pieter Wuille via bitcoin-dev wrote:
> On Sunday, February 19th, 2023 at 6:56 PM, Anthony Towns
> wrote:
> > On Fri, Feb 17, 2023 at 10:13:05PM +, Pieter Wuille via bitcoin-dev
> > wrote:
> > > > I think it's pro
On Fri, Feb 17, 2023 at 10:13:05PM +, Pieter Wuille via bitcoin-dev wrote:
> > I think it's probably less complex to close some of the doors?
> > 2) are short ids available/meaningful to send prior to VERACK being
> > completed?
> Ah, I hadn't considered this nuance. If we don't care about them
On Thu, Feb 16, 2023 at 05:43:22PM +, Dhruv M via bitcoin-dev wrote:
> Problem:
> - 1 byte message type IDs are lacking a co-ordination mechanism when multiple
> in-flight BIPs are proposing new message types as the id space is reduced
> form 12 ASCII bytes to 1 byte.
> - 1 byte IDs are scarc
On Sat, Feb 04, 2023 at 07:11:35PM -0500, Russell O'Connor via bitcoin-dev
wrote:
> Since bytes in the witness are cheaper than bytes in the script pubkey,
> there is a crossover point in data size where it will simply be cheaper to
> use witness data.
Given today's standardness constraints, that
Hi *,
Bitcoin Inquisition 24.0 is tagged with guix builds available:
https://github.com/bitcoin-inquisition/bitcoin/releases/tag/inq-v24.0
It includes support for BIP 118 (ANYPREVOUT) and BIP 119
(CHECKTEMPLATEVERIFY) on regtest and signet.
The main change since 23.0 is simply the rebase on
On Sat, Feb 11, 2023 at 09:40:38AM -0500, Russell O'Connor via bitcoin-dev
wrote:
> Yes. If you would otherwise sign the tapleaf, then I would recommend also
> signing the entire tapbranch.
Opened https://github.com/bitcoin-inquisition/bitcoin/issues/19 for
this.
(I think it's better to call it
On 9 February 2023 12:04:16 am AEST, Russell O'Connor via bitcoin-dev
wrote:
>The fix for the bug is to sign the entire tapbranch instead of the tapleaf.
>
>On Wed., Feb. 8, 2023, 04:35 Michael Folkson,
>wrote:
>
>> Hi Andrew
>>
>> > There is a bug in Taproot that allows the same Tapleaf to be r
On Mon, Apr 11, 2022 at 02:59:16PM -0400, Olaoluwa Osuntokun wrote:
Thread necromancy, but hey.
> > anything about Taro or the way you plan to implement support for
> > transferring fungible assets via asset-aware LN endpoints[1] will address
> > the "free call option" problem, which I think was
On Thu, Feb 02, 2023 at 10:39:21PM -0800, Casey Rodarmor via bitcoin-dev wrote:
> Apologies for posting! I've tried to keep discussion of ordinals and
> inscriptions off-list, because I consider it to be of little relevance to
> general Bitcoin development.
Anything that potentially uses up a larg
Hi *,
Casey Rodarmor's ordinals use the technique of tracking the identity of
individual satoshis throughout their lifetime:
On Tue, Feb 22, 2022 at 04:43:52PM -0800, Casey Rodarmor via bitcoin-dev wrote:
> Briefly, newly mined satoshis are sequentially numbered in the order in
> which they are m
On Tue, Jan 31, 2023 at 01:33:13PM -1000, David A. Harding via bitcoin-dev
wrote:
> I thought the best practice[1] was that wallets would spend to the output
> indicated by any valid bech32m address.
I think it depends -- if the wallet in question is non-custodial and
might not be upgraded by t
uot;, by revealing s.
6) Alice already calculated R and now receives s from Louise when
Louise claims her funds, and (R,s) is a BIP340 signature of m by
Bob, satisfying s*G = R + H(R,P,m)*P, and that signature serves as
her payment receipt from Bob.
Cheers,
aj
On Thu, Jan 26,
On Tue, Jan 10, 2023 at 07:41:09PM +, vwallace via Lightning-dev wrote:
> The open research question relates to how the sender will get an invoice from
> the receiver, given that they are offline at sending-time.
Assuming the overall process is:
* Alice sends a payment to Bob, who has provi
On Mon, Jan 16, 2023 at 11:47:09PM +, Andrew Chow via bitcoin-dev wrote:
> It seems like this proposal will encourage address reuse for vaults,
(That is listed as an explicit goal: "A single vault scriptPubKey should
be able to "receive" multiple deposits")
> However the current construction
Hello world,
I think it's interesting to compare SIGHASH_GROUP [0] and Ephemeral
anchors [1].
[0]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html
[1] https://github.com/bitcoin/bitcoin/pull/26403
SIGHASH_GROUP is the idea that you provide a way for the inputs of a
On Tue, Jan 10, 2023 at 03:22:54PM -0500, James O'Beirne wrote:
> > I don't think that makes sense? With a general scheme, you'd only be
> > bloating the witness data (perhaps including the witness script) not
> > the scriptPubKey?
> Sorry, sloppy language on my part. To be charitable, I'm talking
On Mon, Jan 09, 2023 at 11:07:54AM -0500, James O'Beirne via bitcoin-dev wrote:
> But I also found proposed "general" covenant schemes to be
> unsuitable for this use. The bloated scriptPubKeys,
I don't think that makes sense? With a general scheme, you'd only be
bloating the witness data (perhaps
On Fri, Jan 06, 2023 at 09:12:50AM +1000, Anthony Towns via bitcoin-dev wrote:
> On Thu, Jan 05, 2023 at 10:06:29PM +, Pieter Wuille via bitcoin-dev wrote:
> > Oh, yes. I meant this as an encoding scheme, not as a (replacement for) the
> > negotiation/coordination mechanism. Th
On Thu, Jan 05, 2023 at 06:59:42PM -0500, Antoine Riard wrote:
> > A simple advantage to breaking the symmetry is that if A does a unilateral
> > close, then B can immediately confirm that closure releasing all funds
> > for both parties. Without breaking the symmetry, you can't distinguish
> > tha
On Thu, Jan 05, 2023 at 10:06:29PM +, Pieter Wuille via bitcoin-dev wrote:
> > > So this gives a uniform space which commands can be assigned from, and
> > > there is no strict need for thinking of the short-binary and
> > > long-alphabetic commands as distinct. In v2, some short ones would b
On Wed, Jan 04, 2023 at 01:06:36PM +1100, Lloyd Fournier wrote:
> The advantage of using a covenant
> is that the channel would not have an expiry date and therefore be a first
> class citizen among channels.
I think the approach here would be:
* receive funds on the in-potentiam address with 80
On Tue, Dec 13, 2022 at 08:22:55PM -0500, Antoine Riard wrote:
> > prior to (1): UA.k (k <= n) -- However this allows Bob to immediately
> > broadcast one of either CA.n or RA.n, and will then have ~150 blocks
> > to claim the HTLC before its timeout
> From my understanding, with two party eltoo
On Fri, Dec 09, 2022 at 03:58:37PM +, angus via bitcoin-dev wrote:
> Those in favour of Full RBF see trusting and relying on predictable
> mempool policy as a fundamentally flawed bad idea.
I don't believe that claim is true, at least in general: the motivation
for the -mempoolfullrbf PR was t
Hi *,
Bitcoin Inquisition 23.0 is tagged:
https://github.com/bitcoin-inquisition/bitcoin/releases/tag/inq-v23.0
It includes support for BIP 118 (ANYPREVOUT) and BIP 119
(CHECKTEMPLATEVERIFY) on regtest and signet.
As previously discussed, the hope is that this will allow more
experimentation
On Fri, Dec 09, 2022 at 05:04:05PM +0100, 0xB10C via bitcoin-dev wrote:
> For further monitoring, I've set-up a mempoolfullrbf=1 node and are
> logging replacement events with [0]. I filter the full-RBF replacements
> and list the replaced and replacement transactions here:
> https://fullrbf.mempoo
On Mon, Dec 12, 2022 at 08:38:43PM -0500, Antoine Riard wrote:
> The attack purpose is to delay the confirmation of the final settlement
> transaction S, to double-spend a HTLC forwarded by a routing hop.
> The cltv_expiry_delta requested by Ned is equal to N=144.
I believe what you're suggesting
On Thu, Dec 08, 2022 at 02:14:06PM -0500, Antoine Riard wrote:
> > - 2022-10-21, eltoo/chia:
> https://twitter.com/bramcohen/status/1583122833932099585
> On the eltoo/chia variant, from my (quick) understanding, the main
> innovation aimed for is
I'd say the main innovation aimed for is just doi
Hi all,
On the eltoo irc channel we discussed optimising eltoo for the 2-party
scenario; figured it was probably worth repeating that here.
This is similar to:
- 2018-07-18, simplified eltoo:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-July/001363.html
- 2021-09-17, IID 2St
On Sat, Nov 12, 2022 at 03:23:16AM +, Pieter Wuille via bitcoin-dev wrote:
> Another idea...
> This means:
> * Every alphabetic command of L characters becomes L bytes.
> * 102 non-alphabetic 1-byte commands can be assigned.
> * 15708 non-alphabetic 2-byte commands can be assigned.
(There are
On Tue, Nov 08, 2022 at 01:16:13PM -0500, Peter Todd via bitcoin-dev wrote:
> FYI I've gotten a few hundred dollars worth of donations to this effort, and
> have raised the reward to about 0.02 BTC, or $400 USD at current prices.
Seems like this has been mostly claimed (0.014btc / $235, 9238sat/vb
On Wed, Oct 26, 2022 at 04:39:02PM +, Pieter Wuille via bitcoin-dev wrote:
> However, it obviously raises the question of how the mapping table between the
> 1-byte IDs and the commands they represent should be maintained:
>
> 1. The most straightforward solution is using the BIP process as-is
On Sun, Nov 06, 2022 at 06:22:08PM -0500, Antoine Riard via bitcoin-dev wrote:
> Adding a few more thoughts here on what coinjoins/splicing/dual-funded
> folks can do to solve this DoS issue in an opt-in RBF world only.
>
> I'm converging that deploying a distributed monitoring of the network
> me
On Fri, Oct 28, 2022 at 03:21:53AM +1000, Anthony Towns via bitcoin-dev wrote:
> What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to
> solve that problem if they have only opt-in RBF available?
ref:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/02112
On Mon, Oct 31, 2022 at 12:25:46PM -0400, Greg Sanders via bitcoin-dev wrote:
> For 0-conf services we have potential thieves who are willing
> to *out-bid themselves* to have funds come back to themselves. It's not a
> "legitimate" use-case, but a rational one.
I think that's a huge oversimplific
On Sun, Oct 30, 2022 at 11:02:43AM +1000, Anthony Towns via bitcoin-dev wrote:
> > Some napkin math: there are about 250,000 transactions a day; if
> > we round that up to 100 million a year and assume we only want one
> > transaction per year to fail to initially propagate
On Thu, Oct 27, 2022 at 09:29:47PM +0100, Antoine Riard via bitcoin-dev wrote:
> Let's take the contra.
(I don't think I know that phrase? Is it like "play devil's advocate"?)
> I would say the current post describes the state of Bitcoin Core and
> beyond policy
> rules with a high-degree of exha
On Fri, Oct 28, 2022 at 09:45:09PM -1000, David A. Harding via bitcoin-dev
wrote:
> I think this might be understating the problem. A 95% chance of having
> an outbound peer accept your tx conversely implies 1 in 20 payments will
> fail to propagate on their initial broadcast.
Whether that's ter
On Thu, Oct 27, 2022 at 11:56:45AM +0200, John Carvalho via bitcoin-dev wrote:
> I took the time to read your whole post. Despite a diplomatic tone, I find
> your takeaways from all your references to remain conveniently biased for
> protecting the plan of RBF
Yes, I am heavily biased against zero
On Thu, Oct 27, 2022 at 01:36:47PM +0100, Gloria Zhao wrote:
> > The cutoff for that is probably something like "do 30% of listening
> > nodes have a compatible policy"? If they do, then you'll have about a
> > 95% chance of having at least one of your outbound peers accept your tx,
> > just by ran
Hi *,
TLDR: Yes, this post is too long, and there's no TLDR. If it's any
consolation, it took longer to write than it does to read?
On Tue, Jun 15, 2021 at 12:55:14PM -0400, Antoine Riard via bitcoin-dev wrote:
> Subject: Re: [bitcoin-dev] Proposal: Full-RBF in Bitcoin Core 24.0
> I'm writing to
On Thu, Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via bitcoin-dev wrote:
> > If someone's going to systematically exploit your store via this
> > mechanism, it seems like they'd just find a single wallet with a good
> > UX for opt-in RBF and lowballing fees, and go to town -- not something
>
On Wed, Oct 19, 2022 at 04:29:57PM +0200, Sergej Kotliar via bitcoin-dev wrote:
> The
> biggest risk in accepting bitcoin payments is in fact not zeroconf risk
> (it's actually quite easily managed),
You mean "it's quite easily managed, provided the transaction doesn't
opt-in to rbf", right? At le
On Mon, Oct 17, 2022 at 05:41:48PM -0400, Antoine Riard via bitcoin-dev wrote:
> > 1) Continue supporting and encouraging accepting unconfirmed "on-chain"
> > payments indefinitely
> > 2) Draw a line in the sand now, but give people who are currently
> > accepting unconfirmed txs time to
On Thu, Oct 13, 2022 at 02:35:22PM +1000, Anthony Towns via bitcoin-dev wrote:
> On Wed, Oct 12, 2022 at 04:11:05PM +, Pieter Wuille via bitcoin-dev wrote:
> > In my view, it is just what I said: a step towards getting full RBF
> > on the network, by allowing experimentation
On Wed, Oct 12, 2022 at 04:11:05PM +, Pieter Wuille via bitcoin-dev wrote:
> In my view, it is just what I said: a step towards getting full RBF
> on the network, by allowing experimentation and socializing the notion
> that developers believe it is time.
We "believe it is time" for what exact
On Tue, Oct 11, 2022 at 04:18:10PM +, Pieter Wuille via bitcoin-dev wrote:
> On Friday, October 7th, 2022 at 5:37 PM, Dario Sneidermanis via bitcoin-dev
> wrote:
> > Thanks for the fast answer! It seems I missed the link to the PR, sorry for
> > the
> > confusion. I'm referring to the opt-in
On Sun, Oct 09, 2022 at 12:00:04AM -0700, e...@voskuil.org wrote:
> On Sat, Oct 08, 2022, Anthony Towns via bitcoin-dev wrote:
> > > > > Protocol cannot be defined on an ad-hoc basis as a "courtesy"
> > > > BIPs are a courtesy in the first place.
>
On Sat, Oct 08, 2022 at 12:58:35PM -0700, Eric Voskuil via bitcoin-dev wrote:
> > > Protocol cannot be defined on an ad-hoc basis as a "courtesy"
> > BIPs are a courtesy in the first place.
> I suppose if you felt that you were the authority then this would be your
> perspective.
You seem to thin
On Wed, Oct 05, 2022 at 09:32:29PM -0700, Eric Voskuil via bitcoin-dev wrote:
> Protocol cannot be defined on an ad-hoc basis as a "courtesy"
BIPs are a courtesy in the first place. There's no central authority to
enforce some particular way of doing things.
> - and it's not exactly a courtesy to
On Tue, Oct 04, 2022 at 05:01:04PM -0700, Eric Voskuil via bitcoin-dev wrote:
> [Regarding bandwidth waste: I've pointed out in years past that
> breaking the Bitcoin versioning scheme creates a requirement that any
> unknown message type be considered valid. Up until a recently-deployed
> protocol
On Sun, Oct 02, 2022 at 03:25:19PM +, Michael Folkson via bitcoin-dev wrote:
> I'm also perfectly happy with the status quo of the default signet
> having block signers and gatekeepers for soft forks activated on the
> default signet. I'm more concerned with those gatekeepers being under
> pres
On Fri, Sep 16, 2022 at 05:15:45PM +1000, Anthony Towns via bitcoin-dev wrote:
> So that's the concept. For practical purposes, I haven't yet merged
> either CTV or APO support into the bitcoin-inquisition 23.0 branch yet
I've now merged CTV and updated my signet miner to enf
On Wed, Sep 28, 2022 at 11:48:32AM +, Michael Folkson via bitcoin-dev wrote:
> SegWit was added
> to a new testnet (Segnet) for testing rather than the pre-existing testnet
> and I think future soft fork proposals should follow a similar approach.
I think past history falls into a few groups:
On Thu, Sep 29, 2022 at 12:41:44AM +, ZmnSCPxj wrote:
> > I get what you're saying, but I don't think a "stock of liquidity"
> > is a helpful metaphor/mental model here.
> > "Liquidity" usually means "how easy it is to exchange X for Y" -- assets
> > for cash, etc; but for lightning, liquidity
On Tue, Sep 27, 2022 at 12:23:38AM +, ZmnSCPxj via Lightning-dev wrote:
> All monetisation is fee-based; the question is who pays the fees.
This isn't true. For example, if you can successfully track the payments
you route, you can monetize by selling data about who's buying what
from whom. (U
On Mon, Sep 26, 2022 at 01:26:57AM +, ZmnSCPxj via Lightning-dev wrote:
> > > * you're providing a way of throttling payment traffic independent of
> > > fees -- since fees are competitive, they can have discontinuous effects
> > > where a small change to fee can cause a large change to traffic
On Thu, Sep 22, 2022 at 08:40:30AM +0200, René Pickhardt via Lightning-dev
wrote:
> While trying to estimate the expected liquidity distribution in depleted
> channels due to drain via Markov Models I realized that we can exploit the
> `htlc_maxium_msat` setting to act as a control valve and regul
On Fri, Sep 23, 2022 at 03:13:53PM -0500, lisa neigut wrote:
> Some interesting points here. Will try to respond to some of them.
> > pathfinding algorithms which depend on unscalable data collection
> Failed payment attempts are indistinguishable from data collection probing.
Even so, data collec
On Sun, Sep 18, 2022 at 02:47:38PM -0400, Antoine Riard via bitcoin-dev wrote:
> Said succinctly, in the genesis of creative ideas, evaluation doesn't
> happen at a single clear point but all along the idea lifetime, where this
> evaluation is as much done by the original author than its peers and
On Fri, Sep 16, 2022 at 12:46:53PM -0400, Matt Corallo via bitcoin-dev wrote:
> On 9/16/22 3:15 AM, Anthony Towns via bitcoin-dev wrote:
> > As we've seen from the attempt at a CHECKTEMPLATEVERIFY activation earlier
> > in the year [0], the question of "how to successfull
Subhead: "Nobody expects a Bitcoin Inquistion? C'mon man, *everyone*
expects a Bitcoin Inquisition."
As we've seen from the attempt at a CHECKTEMPLATEVERIFY activation earlier
in the year [0], the question of "how to successfully get soft fork
ideas from concept to deployment" doesn't really have
On Thu, Nov 18, 2021 at 09:29:24PM +0100, Prayank via bitcoin-dev wrote:
> After reading all the emails, personally experiencing review process
> especially on important issues like privacy and security, re-evaluating
> everything and considering the time I can spend on this, I have decided to do
On Fri, Jun 03, 2022 at 06:39:34PM +, alicexbt via bitcoin-dev wrote:
> Covenants on bitcoin will eventually be implemented with a soft fork.
That's begging the question. The issue is whether we should allow such
soft forks, or if the danger of losing coins to covenants and thus
losing fungibi
On Mon, Jul 11, 2022 at 08:21:40PM -0400, Russell O'Connor via bitcoin-dev
wrote:
> Oops, you are right. We need the bribe to be the output of the coinbase,
> but due to the maturity rule, it isn't really a bribe.
> Too bad coinbases cannot take other coinbase outputs as inputs to bypass
> the ma
On Mon, Jul 11, 2022 at 08:56:04AM -0400, Erik Aronesty via bitcoin-dev wrote:
> > Alternatively, losses could be at a predictable rate that's entirely
> > different to the one Peter assumes.
> No, peter only assumes that there *is* a rate.
No, he assumes it's a constant rate. His integration step
On Mon, Jul 11, 2022 at 11:12:52AM -0700, Bram Cohen via bitcoin-dev wrote:
> If transaction fees came in at an even rate over time all at the exact same
> level then they work fine for security, acting similarly to fixed block
> rewards. Unfortunately that isn't how it works in the real world.
Th
On Sat, Jul 09, 2022 at 08:46:47AM -0400, Peter Todd via bitcoin-dev wrote:
> title: "Surprisingly, Tail Emission Is Not Inflationary"
> Of course, this isn't realistic as coins are constantly being lost due to
> deaths, forgotten passphrases, boating accidents, etc. These losses are
> independen
On Thu, Jul 07, 2022 at 10:12:41AM -0400, Peter Todd via bitcoin-dev wrote:
> We should not imbue real technology with magical qualities.
That's much more fun if you invert it, and take it as a mission
statement. Advance technology sufficiently!
> The fact of the matter is that the present amount
1 - 100 of 1026 matches
Mail list logo
