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
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
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
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
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
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
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
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
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
>
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
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 be viewed at
> >>
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
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
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)"
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
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
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 t
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
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
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 probably less complex to close some of
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
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
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,
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 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
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
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
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
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
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
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 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
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
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:
>
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
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,
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
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
>
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
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
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
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
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
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
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
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
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
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
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
>
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
>
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 enforce both CTV a
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 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 successfully get
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
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
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
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
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.
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
>
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
On Tue, May 10, 2022 at 08:05:54PM +0930, Rusty Russell via bitcoin-dev wrote:
> OPTX_SEPARATELY: treat fields separately (vs concatenating)
> OPTX_UNHASHED: push on the stack without hashing (vs SHA256 before push)
> OPTX_SELECT_OUTPUT_AMOUNT32x2*: sats out, as a high-low u31 pair
>
On 24 May 2022 5:05:35 pm GMT-04:00, Gloria Zhao via bitcoin-dev
wrote:
>To clarify, in this situation, I'm imagining something like
>A: 0 sat, 100vB
>B: 1500 sat, 100vB
>C: 0 sat, 100vB
>X: 500 sat, 100vB
>feerate floor is 3sat/vB
>
>With the algo:
>> * is X alone above my fee rate? no, then
On 23 May 2022 9:13:43 pm GMT-04:00, Gloria Zhao wrote:
>> If you're asking for the package for "D", would a response telling you:
>> txid_D (500 sat, 100vB)
>> txid_A (0 sat, 100vB)
>> txid_B (2000 sat, 100 vB)
>> be better, in that case? Then the receiver can maybe do the logic
>>
On Wed, May 18, 2022 at 02:40:58PM -0400, Gloria Zhao via bitcoin-dev wrote:
> > Does it make sense for these to be configurable, rather than implied
> > by the version?
> > … would it be better to either just not do sendpackages
> > at all if you're limiting ancestors in the mempool incompatibly
On Tue, May 17, 2022 at 12:01:04PM -0400, Gloria Zhao via bitcoin-dev wrote:
> New Messages
> Three new protocol messages are added for use in any version of
> package relay. Additionally, each version of package relay must define
> its own inv type and "pckginfo" message version, referred
On Thu, May 12, 2022 at 06:48:44AM -0400, Russell O'Connor via bitcoin-dev
wrote:
> On Wed, May 11, 2022 at 11:07 PM ZmnSCPxj wrote:
> > So really: are recursive covenants good or...?
> My view is that recursive covenants are inevitable. It is nearly
> impossible to have programmable money
On Mon, Apr 25, 2022 at 10:48:20PM -0700, Jeremy Rubin via bitcoin-dev wrote:
> Further, you're representing the state of affairs as if there's a great
> need to scramble to generate software for this, whereas there already are
> scripts to support a URSF that work with the source code I pointed
On Mon, Apr 25, 2022 at 11:26:09AM -0600, Keagan McClelland via bitcoin-dev
wrote:
> > Semi-mandatory in that only "threshold" blocks must signal, so if
> only 4% or 9% of miners aren't signalling and the threshold is set
> at 95% or 90%, no blocks will be orphaned.
> How do nodes decide
On Mon, Apr 25, 2022 at 10:11:45AM -0600, Keagan McClelland via bitcoin-dev
wrote:
> > Under *any* other circumstance, when they're used to activate a bad soft
> > fork, speedy trial and bip8 are the same. If a resistance method works
> > against bip8, it works against speedy trial; if it fails
On Sun, Apr 24, 2022 at 12:13:08PM +0100, Jorge Timón wrote:
> You're not even considering user resistance in your cases.
Of course I am. Again:
> > My claim is that for *any* bad (evil, flawed, whatever) softfork, then
> > attempting activation via bip8 is *never* superior to speedy trial,
> >
On Thu, Apr 21, 2022 at 10:05:20AM -0500, Jeremy Rubin via bitcoin-dev wrote:
> I can probably make some show up sometime soon. Note that James' vault uses
> one at the top-level https://github.com/jamesob/simple-ctv-vault, but I
> think the second use of it (since it's not segwit wrapped)
On Wed, Apr 20, 2022 at 03:04:53PM -1000, David A. Harding via bitcoin-dev
wrote:
> The main criticisms I'm aware of against CTV seem to be along the following
> lines: [...]
> Could those concerns be mitigated by making CTV an automatically reverting
> consensus change with an option to renew?
On Wed, Apr 20, 2022 at 05:13:19PM +, Buck O Perley via bitcoin-dev wrote:
> All merits (or lack thereof depending on your view) of CTV aside, I find this
> topic around decision making both interesting and important. While I think I
> sympathize with the high level concern about making sure
On Wed, Apr 20, 2022 at 08:05:36PM +0300, Nadav Ivgi via bitcoin-dev wrote:
> > I didn't think DROP/1 is necessary here? Doesn't leaving the 32 byte hash
> on the stack evaluate as true?
> Not with Taproot's CLEANSTACK rule.
The CLEANSTACK rule is the same for segwit and tapscript though?
For
On Thu, Feb 17, 2022 at 01:58:38PM -0800, Jeremy Rubin via bitcoin-dev wrote:
> AJ Wrote (in another thread):
> > I'd much rather see some real
> > third-party experimentation *somewhere* public first, and Jeremy's CTV
> > signet being completely empty seems like a bad sign to me.
There's
On Fri, Apr 08, 2022 at 11:58:48AM +0200, Jorge Timón via bitcoin-dev wrote:
> On Wed, Mar 30, 2022 at 6:21 AM Anthony Towns wrote:
> > > Let's discuss those too. Feel free to point out how bip8 fails at some
> > > hypothetical cases speedy trial doesn't.
> > Any case where a flawed proposal
On Mon, Mar 28, 2022 at 09:31:18AM +0100, Jorge Timón via bitcoin-dev wrote:
> > In particular, any approach that allows you to block an evil fork,
> > even when everyone else doesn't agree that it's evil, would also allow
> > an enemy of bitcoin to block a good fork, that everyone else correctly
On Thu, Mar 24, 2022 at 07:30:09PM +0100, Jorge Timón via bitcoin-dev wrote:
> Sorry, I won't answer to everything, because it's clear you're not listening.
I'm not agreeing with you; that's different to not listening to you.
> In the HYPOTHETICAL CASE that there's an evil for, the fork being
On Thu, Mar 17, 2022 at 03:04:32PM +0100, Jorge Timón via bitcoin-dev wrote:
> On Tue, Mar 15, 2022 at 4:45 PM Anthony Towns wrote:
> > On Fri, Mar 11, 2022 at 02:04:29PM +, Jorge Timón via bitcoin-dev wrote:
> > People opposed to having taproot transactions in their chain had over
> > three
On Wed, Mar 16, 2022 at 02:54:05PM +, ZmnSCPxj via bitcoin-dev wrote:
> My point is that in the past we were willing to discuss the complicated
> crypto math around cross-input sigagg in order to save bytes, so it seems to
> me that cross-input compression of puzzles/solutions at least
On Tue, Mar 22, 2022 at 05:37:03AM +, ZmnSCPxj via bitcoin-dev wrote:
> Subject: Beyond Jets: Microcode: Consensus-Critical Jets Without Softforks
(Have you considered applying a jit or some other compression algorithm
to your emails?)
> Microcode For Bitcoin SCRIPT
>
On Fri, Mar 11, 2022 at 02:04:29PM +, Jorge Timón via bitcoin-dev wrote:
> > Thirdly, if some users insist on a chain where taproot is
> > "not activated", they can always softk-fork in their own rule that
> > disallows the version bits that complete the Speedy Trial activation
> > sequence,
On Tue, Mar 08, 2022 at 03:06:43AM +, ZmnSCPxj via bitcoin-dev wrote:
> > > They're radically different approaches and
> > > it's hard to see how they mix. Everything in lisp is completely sandboxed,
> > > and that functionality is important to a lot of things, and it's really
> > > normal to
On Tue, Mar 08, 2022 at 06:54:56PM -0800, Bram Cohen via bitcoin-dev wrote:
> On Mon, Mar 7, 2022 at 5:27 PM Anthony Towns wrote:
> > One way to match the way bitcoin do things, you could have the "list of
> > extra conditions" encoded explicitly in the transaction via the annex,
> > and then
On Sun, Mar 06, 2022 at 10:26:47PM -0800, Bram Cohen via bitcoin-dev wrote:
> > After looking into it, I actually think chia lisp [1] gets pretty much all
> > the major design decisions pretty much right. There are obviously a few
> > changes needed given the differences in design between chia and
1 - 100 of 254 matches
Mail list logo
