On Wed, Dec 13, 2017 at 01:46:09PM -0600, Jimmy Song via bitcoin-dev wrote:
> Hey all,
>
> I am proposing an informational BIP to standardize the term "bits". The
> term has been around a while, but having some formal informational standard
> helps give structure to how the term is used.
>
> http
On Sun, Jan 28, 2018 at 05:43:34PM +0100, Sjors Provoost via bitcoin-dev wrote:
> Peter Todd wrote:
> > In fact I considered only requiring an increase in fee rate, based on the
> > theory that if absolute fee went down, the transaction must be smaller and
> > thus
> > miners could overall earn mo
On Fri, Jun 01, 2018 at 07:02:38PM -0700, Jim Posen via bitcoin-dev wrote:
> Without the ability to verify filter validity, a client would have to stop
> syncing altogether in the presence of just one malicious peer, which is
> unacceptable.
I'm confused about why this would be the case. If Alice
On Fri, Jun 08, 2018 at 04:35:29PM -0700, Olaoluwa Osuntokun via bitcoin-dev
wrote:
> 2. Since the coinbase transaction is the first in a block, it has the
> longest merkle proof path. As a result, it may be several hundred bytes
> (and grows with future capacity increases) to present
On Thu, Dec 06, 2018 at 11:57:09AM -0500, Russell O'Connor via bitcoin-dev
wrote:
> One more item to consider is "signature covers witness weight".
>
> While signing the witness weight doesn't completely eliminate witness
> malleability (of the kind that can cause grief for compact blocks), it do
On Tue, Dec 11, 2018 at 10:36:59AM -0500, Russell O'Connor wrote:
> I don't believe that the default RBF policy works that way. My
> understanding is that current policy requires an absolute fee increase (by
> an amount related to incrementalrelayfee).
Indeed, you are correct (BIP125 rule 4[1])
On Sun, Mar 10, 2019 at 09:43:43AM +0900, Karl-Johan Alm via bitcoin-dev wrote:
> Keeping the PoW rule and moving the signature would mean DoS attacks
> would be trivial as anyone could mine blocks without a signature in
> them
Sure, but anyone could also just connect their lite client to a truste
On Fri, Mar 22, 2019 at 10:04:46PM +0100, Jonas Schnelli via bitcoin-dev wrote:
> === v2 Messages Structure ===
>
> {|class="wikitable"
> ! Field Size !! Description !! Data type !! Comments
> [...]
> | 1-13 || encrypted command || variable || ASCII command (or one byte short
> command ID)
> [...
On Sun, Mar 24, 2019 at 09:29:10AM -0400, David A. Harding via bitcoin-dev
wrote:
> Why is this optional and only specified here for some message types
> rather than being required by v2 and specified for all message types?
Gregory Maxwell discussed this with me on IRC[1]. My summary
On Thu, Jun 06, 2019 at 02:46:54PM +0930, Rusty Russell via bitcoin-dev wrote:
> Matt Corallo writes:
> > 2) wrt rule 4, I'd like to see a calculation of worst-case free
> > relay. I think we're already not in a great place, but maybe it's
> > worth it or maybe there is some other way to reduce th
On Fri, Jun 28, 2019 at 10:27:16AM +0200, Tamas Blummer via bitcoin-dev wrote:
> The value of these outputs to Charlie is the proof that he has
> exclusive control of the coins until maturity.
>
> Alice can not issue promissory notes in excess of own capital or
> capital that she was able to borrow
On Thu, Jul 25, 2019 at 12:47:54PM +0100, Chris Belcher via bitcoin-dev wrote:
> A way to create a fidelity bond is to burn an amount of bitcoins by
> sending to a OP_RETURN output. Another kind is time-locked addresses
> created using OP_CHECKLOCKTIMEVERIFY where the valuable thing being
> sacrifi
On Tue, Jul 30, 2019 at 10:27:17PM +0100, Chris Belcher wrote:
> And any ECC-alternative or hash-function-alternative fork will
> probably take a couple of months to be designed, implemented and
> deployed as well, giving a chance for lockers to move coins.
Probably. A stronger form of my argumen
On Sun, Sep 08, 2019 at 05:39:28AM +0200, Ruben Somsen via bitcoin-dev wrote:
> After looking more deeply into Tadge Dryja’s utreexo work [0], it has
> become clear to me that this opens up a way to implement PoW fraud
> proofs [1] without a soft fork.
This is a nifty idea.
> [...] you’d need to
On Thu, Oct 03, 2019 at 05:38:36PM -0700, Braydon Fuller via bitcoin-dev wrote:
> This paper describes a solution [to DoS attacks] that does not
> require enabling or maintaining checkpoints and provides improved security.
> [...]
> The paper is available at:
> https://bcoin.io/papers/bitcoin-chai
On Thu, Oct 17, 2019 at 01:16:47PM -0700, Eric Voskuil via bitcoin-dev wrote:
> As this is a P2P protocol change it should be exposed as a version
> increment (and a BIP) [...]
>
> BIP61 is explicit:
>
> “All implementations of the P2P protocol version 70,002 and later
> should support the reject
On Sun, Oct 20, 2019 at 12:29:25AM +, SomberNight via bitcoin-dev wrote:
> waxwing, ThomasV, and I recently had a discussion about implementing
> SNICKER in Electrum; specifically the "Receiver" role.
That'd be awesome!
> As the referenced section [0] explains, the "Receiver" can restore
> f
On Thu, Oct 24, 2019 at 03:49:09PM +0200, Johan Torås Halseth wrote:
> [...] what about letting the rule be
>
> The last transaction which is added to a package of dependent
> transactions in the mempool must:
> * Have no more than one unconfirmed parent.
> [... subsequent email ...]
> I realize
On Mon, Oct 28, 2019 at 10:45:39AM +0100, Johan Torås Halseth wrote:
> Relay cost is the obvious problem with just naively removing all limits.
> Relaxing the current rules by allowing to add a child to each output as
> long as it has a single unconfirmed parent would still only allow free
> relay
On Thu, Nov 07, 2019 at 02:35:42PM -0800, Pieter Wuille via bitcoin-dev wrote:
> In the current draft, witness v1 outputs of length other
> than 32 remain unencumbered, which means that for now such an
> insertion or erasure would result in an output that can be spent by
> anyone. If that is consid
On Fri, Jan 31, 2020 at 03:42:08AM +, ZmnSCPxj via bitcoin-dev wrote:
> Let me then propose a specific mechanism for feerate insurance against
> onchain feerate spikes.
>
> [...]
>
> At current blockheight B, Alice and Ingrid then arrange a series of
> transactions:
>
> nLockTime: B+1
On Sun, Feb 09, 2020 at 02:47:29PM -0600, Anon via Bryan Bishop via bitcoin-dev
wrote:
> 1) Is Taproot actually more private than bare MAST and Schnorr separately?
Yes.
> What are the actual anonymity set benefits compared to doing the separately?
When schnorr and taproot are done together, all
On Fri, Feb 14, 2020 at 12:07:15PM -0800, Jeremy via bitcoin-dev wrote:
> Is the same if Schnorr + Merkle Branch without Taproot optimization, unless
> I'm missing something in one of the cases?
That's fair. However, it's only true if everyone constructs their
merkle tree in the same way, with a
On Sat, Mar 21, 2020 at 11:40:24AM -0700, Dave Scotese via bitcoin-dev wrote:
> [Imagine] we also see mining power dropping off at a rate that
> suggests the few days [until retarget] might become a few weeks, and
> then, possibly, a few months or even the unthinkable, a few eons. I'm
> curious to
On Wed, Mar 25, 2020 at 01:52:10PM +, Tom Trevethan via bitcoin-dev wrote:
> Hi all,
>
> We are starting to work on an implementation of the statechains concept (
> https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39),
>
> [...]
> There are two mai
On Tue, Apr 21, 2020 at 09:13:34PM -0700, Olaoluwa Osuntokun wrote:
> On Mon, Apr 20, 2020 at 10:43:14PM -0400, Matt Corallo via Lightning-dev
> wrote:
> > While this is somewhat unintuitive, there are any number of good anti-DoS
> > reasons for this, eg:
>
> None of these really strikes me as "g
On Mon, Apr 20, 2020 at 10:43:14PM -0400, Matt Corallo via Lightning-dev wrote:
> A lightning counterparty (C, who received the HTLC from B, who
> received it from A) today could, if B broadcasts the commitment
> transaction, spend an HTLC using the preimage with a low-fee,
> RBF-disabled transacti
On Wed, Apr 22, 2020 at 03:03:29PM -0400, Antoine Riard wrote:
> > In that case, would it be worth re-implementing something like a BIP61
> reject message but with an extension that returns the txids of any
> conflicts?
>
> That's an interesting idea, but an attacker can create a local conflict in
On Fri, Nov 13, 2015 at 08:27:48AM +0100, Jonas Schnelli via bitcoin-dev wrote:
> I'm a little bit concerned about the future of bitcoin.org.
Bitcoin.org hosts the Bitcoin Core binaries refered to in release
announcements, so this subject is conceivably on-topic for bitcoin-dev.
However, I think q
On Fri, Jan 22, 2016 at 04:36:58PM +, Andrew C via bitcoin-dev wrote:
> Spending a time locked output requires setting nSequence to less than
> MAX_INT but opting into RBF also requires setting nSequence to less than
> MAX_INT.
Hi Andrew,
Opt-in RBF requires setting nSequence to less than MA
On Wed, Mar 02, 2016 at 02:56:14PM +, Luke Dashjr via bitcoin-dev wrote:
> To alleviate this risk, it seems reasonable to propose a hardfork to the
> difficulty adjustment algorithm so it can adapt quicker to such a significant
> drop in mining rate.
Having a well-reviewed hard fork patch fo
On Wed, Mar 02, 2016 at 05:53:46PM +, Gregory Maxwell wrote:
> What you are proposing makes sense only if it was believed that a very
> large difficulty drop would be very likely.
>
> This appears to be almost certainly untrue-- consider-- look how long
> ago since hashrate was 50% of what it i
Hi,
Arguing about which wiki is better doesn't feel productive to me. Can we
just let BIP authors decide for themselves? Draft-BIP2 already has a
provision for allowing authors to specify a backup wiki of their own
choosing; can we just make that the policy in all cases (and drop the
need for a ba
On Thu, Aug 27, 2015 at 12:38:42PM +0930, Rusty Russell via bitcoin-dev wrote:
> So I'd like an IsStandard() rule to say it nLockTime be 0 if an
> nSequence != 0x. Would that screw anyone currently?
That sentence doesn't quite parse ("say it nLockTime"), so please
forgive me if I'm misunde
On Wed, Apr 22, 2020 at 03:53:37PM -0700, Matt Corallo wrote:
> if you focus on sending the pinning transaction to miner nodes
> directly (which isn't trivial, but also not nearly as hard as it
> sounds), you could still pull off the attack.
If the problem is that miners might have information no
On Wed, Apr 29, 2020 at 04:57:46PM +0200, Andrew Kozlik via bitcoin-dev wrote:
> In order to ascertain non-ownership of an input which is claimed to be
> external, the wallet needs the scriptPubKey of the previous output spent by
> this input.
A wallet can easily check whether a scriptPubKey conta
On Fri, Jun 19, 2020 at 09:44:11AM +0200, Bastien TEINTURIER via Lightning-dev
wrote:
> The gist is here, and I'd appreciate your feedback if I have wrongly
> interpreted some of the ideas:
> https://gist.github.com/t-bast/22320336e0816ca5578fdca4ad824d12
Quoted text below is from the gist:
> Th
On Fri, Jun 19, 2020 at 03:58:46PM -0400, David A. Harding via bitcoin-dev
wrote:
> I think you're assuming here that the attacker broadcast a particular
> state.
Whoops, I managed to confuse myself despite looking at Bastien's
excellent explainer. The attacker would be
On Sat, Jun 20, 2020 at 10:54:03AM +0200, Bastien TEINTURIER wrote:
> We're simply missing information, so it looks like the only good
> solution is to avoid being in that situation by having a foot in
> miners' mempools.
The problem I have with that approach is that the incentive is to
connect to
On Tue, Jun 23, 2020 at 09:41:56AM +0300, Stanga via bitcoin-dev wrote:
> Hi all,
>
> We'd like to bring to your attention our recent result concerning HTLC.
> Here are the technical report and a short post outlining the main points:
>
> * https://arxiv.org/abs/2006.12031
> * https://ittayeyal.gi
On Tue, Jun 23, 2020 at 03:47:56PM +0300, Stanga via bitcoin-dev wrote:
> On Tue, Jun 23, 2020 at 12:48 PM ZmnSCPxj wrote:
> > * Inputs:
> > * Bob 1 BTC - HTLC amount
> > * Bob 1 BTC - Bob fidelity bond
> >
> > * Cases:
> > * Alice reveals hashlock at any time:
> > * 1 BTC goes to Alice
On Thu, Jul 02, 2020 at 09:28:39PM +0500, Dmitry Petukhov via bitcoin-dev wrote:
> I think there should be standard format to describe constraints for
> BIP32 paths.
>
> I present a BIP draft that specifies "path templates" for BIP32 paths:
>
> https://github.com/dgpv/bip32_template_parse_tplaplu
On Sun, Aug 16, 2020 at 12:06:55PM -0700, Eric Voskuil via bitcoin-dev wrote:
> A requirement to ignore unknown (invalid) messages is [...] a protocol
> breaking change
I don't think it is. The proposed BIP, as currently written, only tells
nodes to ignore unknown messages during peer negotiatio
On Sun, Aug 16, 2020 at 11:41:30AM -0400, Thomas Hartman via bitcoin-dev wrote:
> First, I would like to pay respects to tamas blummer, RIP.
>
> https://bitcoinmagazine.com/articles/remembering-tamas-blummer-pioneering-bitcoin-developer
RIP, Tamas.
> Tamas proposed an additional opcode for enabl
On Fri, Sep 18, 2020 at 05:51:39PM -0700, Jeremy via bitcoin-dev wrote:
> I'd like to share with you a draft proposal for a mechanism to replace
> CPFP and RBF for increasing fees on transactions in the mempool that
> should be more robust against attacks.
Interesting idea! This is going to take
On Sat, Sep 19, 2020 at 09:30:56AM -0700, Jeremy wrote:
> Yup, I was aware of this limitation but I'm not sure how practical it is as
> an attack because it's quite expensive for the attacker.
It's cheap if:
1. You were planning to consolidate all those UTXOs at roughly that
feerate anyway.
On Sun, Sep 20, 2020 at 07:10:23PM -0400, Antoine Riard via bitcoin-dev wrote:
> As you mentioned, if the goal of the sponsor mechanism is to let any party
> drive a state N's first tx to completion, you still have the issue of
> concurrent states being pinned and thus non-observable for sponsoring
On Fri, Sep 25, 2020 at 10:35:36AM -0700, Mike Brooks via bitcoin-dev wrote:
> - with a fitness test you have a 100% chance of a new block from being
> accepted, and only a 50% or less chance for replacing a block which has
> already been mined. This is all about keeping incentives moving forwar
On Thu, Oct 08, 2020 at 10:51:10AM +1030, Rusty Russell via bitcoin-dev wrote:
> Hi all,
>
> I propose an alternative to length restrictions suggested by
> Russell in https://github.com/bitcoin/bips/pull/945 : use the
> https://gist.github.com/sipa/a9845b37c1b298a7301c33a04090b2eb variant,
On Tue, Oct 20, 2020 at 11:12:06AM +1030, Rusty Russell wrote:
> Here are my initial results:
A while ago, around the Bitcoin Core 0.19.0 release that enabled
relaying v1+ segwit addresses, Mike Schmidt was working on the Optech
Compatibility Matrix[1] and tested a variety of software and services
On Sat, Dec 05, 2020 at 11:10:51PM +, Pieter Wuille via bitcoin-dev wrote:
> I think these results really show there is no reason to try to
> maintain the old-software-can-send-to-future-segwit-versions property,
> given that more than one not just didn't support it, but actually sent
> coins i
On Fri, Feb 05, 2021 at 12:43:57PM +, Michael Folkson via bitcoin-dev wrote:
> https://old.reddit.com/r/Bitcoin/comments/lcjhl6/taproot_activation_pools_will_be_able_to_veto/gm2l02w/
> [...]
> F6) It is more important that no rules that harm users are deployed
> than it is that new useful rule
On Fri, Feb 26, 2021 at 11:40:35AM -0700, Keagan McClelland via bitcoin-dev
wrote:
> Hi all,
Hi Keagan,
> 4. Once the node's IBD is complete it would advertise this as a peer
> service, advertising its seed and threshold, so that nodes could
> deterministically deduce which of its peers had whic
On Sat, Feb 27, 2021 at 09:19:34AM -1000, David A. Harding via bitcoin-dev
wrote:
> - Discussion thread 1:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014186.html
Two particularly useful emails from that thread are:
- https://lists.linuxfoundation.org/pipermail/b
On the ##taproot-activation IRC channel, Russell O'Connor recently
proposed a modification of the "Let's see what happens" activation
proposal.[1] The idea received significant discussion and seemed
acceptable to several people who could not previously agree on a
proposal (although this doesn't nec
On Sat, Mar 06, 2021 at 01:11:01PM -0500, Matt Corallo wrote:
> I'm really unsure that three months is a short enough time window that there
> wouldn't be a material effort to split the network with divergent consensus
> rules.
I oppose designing activation mechanisms with the goal of preventing
On Mon, Mar 15, 2021 at 09:48:15PM +, Luke Dashjr via bitcoin-dev wrote:
> Note that in all circumstances, Bitcoin is endangered when QC becomes
> a reality [...] it could very well become an unrecoverable situation
> if QC go online prior to having a full quantum-safe solution.
The main conce
On Tue, Apr 06, 2021 at 10:34:57AM -0400, Russell O'Connor via bitcoin-dev
wrote:
> The other relevant value of giving enough time for users to upgrade is not
> very sensitive. It's not like 180 days is magic number that going over is
> safe and going below is unsafe.
I don't think it's the 180
(Replies to multiple emails)
On Tue, Apr 06, 2021 at 12:27:34PM -0400, Russell O'Connor wrote:
> It isn't "$MIN_LOCKIN_TIME + $((10 * 2016)) minutes". It's
> "$MIN_LOCKIN_TIME + time until next retargeting period + $((10 * 2016))
> minutes".
Ah, drat, I forgot about that. Thank you for correcti
On Thu, Apr 08, 2021 at 12:40:42PM +0100, Michael Folkson via bitcoin-dev wrote:
> So the latest circus act is apparently a technical decision made by a
> coin toss [organized by] Jeremy Rubin
Actually, the coin toss was my idea[1], used a bash oneliner I wrote[2],
and is the same method I've been
On Tue, Apr 20, 2021 at 08:46:07AM -0700, Jeremy via bitcoin-dev wrote:
> Script is technically "too wide" a type as what I really want is to
> only return coins with known output types.
I don't understand this concern. If script is too wide a type, then
OP_RETURN being a scriptPubKey of arbitrar
On Sat, Apr 24, 2021 at 01:05:25PM -0700, Jeremy wrote:
> I meant the type itself is too wide, not the length of the value. As in
> Script can represent things we know nothing about.
I guess I still don't understand your concern, then. If script can
represent things we know nothing about, then s
On Sat, Apr 24, 2021 at 04:42:12AM +, Greg Maxwell via bitcoin-dev wrote:
> I am opposed to the addition of Kalle Alm at this time. Those who
> believe [this] will resolve the situation [...] re: PR1104 are
> mistaken.
PR1104 has been merged. Do you continue to oppose the addition?
Thanks,
On Sun, Apr 25, 2021 at 05:31:50PM -0400, Matt Corallo via bitcoin-dev wrote:
> In general, I think its time we all agree the BIP process has simply failed
> and move on. Luckily its not really all that critical and proposed protocol
> documents can be placed nearly anywhere with the same effect.
On Fri, Jun 18, 2021 at 06:11:38PM -0400, Antoine Riard wrote:
> 2) Solving the Pre-Signed Feerate problem : Package-Relay or
> SIGHASH_ANYPREVOUT
>
> For Lightning, either package-relay or SIGHASH_ANYPREVOUT should be able to
> solve the pre-signed feerate issue [3]
>
> [...]
>
> [3] I don't thin
On Tue, Jun 29, 2021 at 09:14:39PM +, Andrew Chow via bitcoin-dev wrote:
> *** Optionally followed by a single /* or /*' final
> step to denote all direct unhardened or hardened children.
>
> [...]
>
> In the above specification, the hardened indicator ' may be
> replaced with alternative har
On Sat, Jul 03, 2021 at 10:35:48AM +0200, Craig Raw wrote:
> There is a downside to using "h"/"H" from a UX perspective - taking up more
> space
Is this a serious concern of yours? An apostrophe is 1/2 en; an "h" is
1 en; the following descriptor contains three hardened derivations in 149
charac
On Sat, Jul 03, 2021 at 09:31:57AM -0700, Jeremy via bitcoin-dev wrote:
> Note that with *just* CheckSigFromStack, while you can do some very
> valuable use cases, but without OP_CAT it does not enable sophisticated
> covenants
Do you have concerns about sophisticated covenants, and if so, would y
On Sun, Jul 04, 2021 at 11:39:44AM -0700, Jeremy wrote:
> However, I think the broader community is unconvinced by the cost benefit
> of arbitrary covenants. See
> https://medium.com/block-digest-mempool/my-worries-about-too-generalized-covenants-5eff33affbb6
> as a recent example. Therefore as a c
On Fri, Jul 16, 2021 at 04:35:21PM +0200, Karel Kyovsky via bitcoin-dev wrote:
> I would like to propose a standardization of [a new] bitcoin URI parameter
> name
> [...]
> My question is: Should I prepare a completely new BIP or should I prepare a
> modification of BIP21?
Please use a new BIP.
On Tue, Jul 20, 2021 at 07:44:19PM +, Michael Flaxman via bitcoin-dev wrote:
> I've been working on ways to prevent privacy leaks in multisig
> quorums, and have come up with a creative use of BIP32 paths.
It seems to me like it would be rare for an attacker to obtain a private
BIP32 seed but
On Tue, Jul 20, 2021 at 10:56:10PM -0700, Billy Tetrud via bitcoin-dev wrote:
> This involves [...] constraining the amount of the fee that output is
> allowed to contribute to. [...] fee is specified relative to recent
> median fee rates - details in the proposal).
Here are the relevant details:
On Sun, Jul 25, 2021 at 12:49:38PM -0700, Billy Tetrud wrote:
> find the median fee-rate for each block and store that, then calculate
> the average of those stored per-block median numbers.
One datapoint per block seems fine to me and it works much nicer with
pruned nodes.
> So the only situati
On Sun, Aug 08, 2021 at 11:52:55AM -0700, Jeremy wrote:
> We should remove the dust limit from Bitcoin. Five reasons:
Jeremy knows this, but to be clear for other readers, the dust limit is
a policy in Bitcoin Core (and other software) where it refuses by
default to relay or mine transactions with
On Mon, Aug 09, 2021 at 09:22:28AM -0400, Antoine Riard wrote:
> I'm pretty conservative about increasing the standard dust limit in any
> way. This would convert a higher percentage of LN channels capacity into
> dust, which is coming with a lowering of funds safety [0].
I think that reasoning i
On Fri, Sep 03, 2021 at 08:32:19PM -0700, Jeremy via bitcoin-dev wrote:
> Hi Bitcoin Devs,
>
> I recently noticed a flaw in the Sequence lock implementation with respect
> to upgradability. It might be the case that this is protected against by
> some transaction level policy (didn't see any in po
On Wed, Sep 01, 2021 at 11:46:55PM -0700, Billy Tetrud via bitcoin-dev wrote:
> How would you compare this to Stratum v2?
Specifically, I'd be interested in learning what advantages this has
over a centralized mining pool using BetterHash or StratumV2 with
payouts made via LN (perhaps immediately
On Mon, Sep 06, 2021 at 09:29:01AM +0200, Eric Voskuil wrote:
> It doesn’t centralize payment, which ultimately controls transaction
> selection (censorship).
Yeah, but if you get paid after each share via LN and you can switch
pools instantly, then the worst case with centralized pools is that
On Fri, Sep 10, 2021 at 11:24:15AM -0700, Matt Corallo via bitcoin-dev wrote:
> I'm [...] suggesting [...] that the existing block producers each
> generate a new key, and we then only sign reorgs with *those* keys.
> Users will be able to set a flag to indicate "I want to accept sigs
> from either
On Wed, Nov 17, 2021 at 08:05:55PM +, n1ms0s via bitcoin-dev wrote:
> This seems to be the case. I saw your reply on Bitcoin StackExchange
> as well. In bitcoinj I just made it so the client only connects to
> nodes with at least protocol version 70016. Seems to work well.
Hi,
This is a cleve
On Mon, Feb 07, 2022 at 08:34:30PM -0800, Jeremy Rubin via bitcoin-dev wrote:
> Whether [recursive covenants] is an issue or not precluding this sort
> of design or not, I defer to others.
For reference, I believe the last time the merits of allowing recursive
covenants was discussed at length on
On Tue, Feb 15, 2022 at 01:37:43PM -0800, Jeremy Rubin via bitcoin-dev wrote:
> Unfortunately, there are technical reasons for sponsors to not be monotone.
> Mostly that it requires the maintenance of an additional permanent
> TX-Index
Alternatively, you could allow a miner to include a sponsor tr
Hi all,
The main criticisms I'm aware of against CTV seem to be along the
following lines:
1. Usage, either:
a. It won't receive significant real-world usage, or
b. It will be used but we'll end up using something better later
2. An unused CTV will need to be supported forever, creating ex
On 21.04.2022 04:58, Matt Corallo wrote:
On 4/20/22 6:04 PM, David A. Harding via bitcoin-dev wrote:
The main criticisms I'm aware of against CTV seem to be along the
following lines:
1. Usage, either:
a. It won't receive significant real-world usage, or
b. It will be used but
On 21.04.2022 08:39, Matt Corallo wrote:
We add things to Bitcoin because (a) there's some demonstrated
use-cases and intent to use the change (which I think we definitely
have for covenants, but which only barely, if at all, suggests
favoring one covenant design over any other)
I'm unconvinced
[Rearranging Matt's text in my reply so my nitpicks come last.]
On 21.04.2022 13:02, Matt Corallo wrote:
I agree, there is no universal best, probably. But is there a concrete
listing of a number of use-cases and the different weights of things,
plus flexibility especially around forward-looking
On 21.04.2022 14:28, Anthony Towns wrote:
But, if [it's true that "many [...] use cases [...] to use CTV for
are very long term in nature"], that's presumably incompatible
with any sort of sunset that's less than many decades away, so doesn't
seem much better than just having it be available on a
On 2022-05-10 08:53, Greg Sanders via bitcoin-dev wrote:
We add OPTX_SELECT_WEIGHT(pushes tx weight to stack, my addition to
the proposal) to the "state" input's script.
This is used in the update transaction to set the upper bound on the
final transaction weight.
In this same input, for each con
On 2022-07-10 07:27, Peter Todd via bitcoin-dev wrote:
The block subsidy directly ties miner revenue to the total value of
Bitcoin:
that's exactly how you want to incentivise a service that keeps Bitcoin
secure.
I'm confused. I thought your argument in the OP of this thread was that
a perpet
On 2022-07-26 02:45, Peter Todd via bitcoin-dev wrote:
On Tue, Jul 26, 2022 at 01:56:05PM +0530, Aaradhya Chauhan via
bitcoin-dev wrote:
[...] in its early days, 1 sat/vB was a good dust protection
measure. But now, I think it's a bit high [...] I think it can be done
easily [...]
[...] lower
On 2022-08-19 06:33, James O'Beirne via bitcoin-dev wrote:
Multiple parties could
trustlessly collaborate to settle into a single CTV output using
SIGHASH_ALL | ANYONECANPAY. This requires a level of interaction
similar to coinjoins.
Just to make sure I understand, is the reason for SH_ALL|SH_A
On 2022-09-29 05:39, Ruben Somsen via bitcoin-dev wrote:
An alternative mitigation (more user friendly, but more implementation
complexity) would be to require the sender to reveal their intended
transaction to the server prior to receiving the address[^9]. This is
not a privacy degradation, sinc
On 2022-10-07 06:20, Dario Sneidermanis via bitcoin-dev wrote:
Hello list,
I'm Dario, from Muun wallet [...] we've been reviewing the latest
bitcoin core release
candidate [...] we understood we had at least a year from the initial
opt-in deployment until opt-out was deployed, giving us enoug
On 2022-10-20 09:58, Anthony Towns via bitcoin-dev wrote:
On Thu, Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via
bitcoin-dev wrote:
AJ previously wrote:
> presumably that makes your bitcoin
> payments break down as something like:
>5% txs are on-chain and seem shady and are excluded fr
On 2022-10-19 04:29, 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), it's FX risk as the merchant must
commit to a certain BTCUSD rate ahead of time for a purchase. Over
time some transactions
On 2022-10-26 13:52, Anthony Towns via bitcoin-dev 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 random chance.
I
On 2022-11-07 23:17, Salvatore Ingala via bitcoin-dev wrote:
Hi list,
Hi Salvatore!,
I have been working on some notes to describe an approach that uses
covenants in order to enable general smart contracts in bitcoin. You
can find them here:
https://merkle.fun
I haven't yet been able t
On 2022-11-07 11:17, Peter Todd via bitcoin-dev wrote:
We can ensure with high probability that the transaction can be
cancelled/mined
at some point after N blocks by pre-signing a transaction, with
nLockTime set
sufficiently far into the future, spending one or more inputs of the
transaction w
On 2023-01-09 12:18, Peter Todd via bitcoin-dev wrote:
[The quote:]
"Does fullrbf offer any benefits other than breaking zeroconf
business
practices?"
...has caused a lot of confusion by implying that there were no
benefits. [...]
tl;dr: without full-rbf people can intentionally a
On 2023-01-09 22:47, Peter Todd wrote:
How do you propose that the participants learn about the double-spend?
Without
knowing that it happened, they can't respond as you suggested.
I can think of various ways---many of them probably the same ideas that
would occur to you. More concise than li
1 - 100 of 128 matches
Mail list logo
