On 10/20/23 7:43 PM, Peter Todd wrote:
On Fri, Oct 20, 2023 at 09:55:12PM -0400, Matt Corallo wrote:
Quite the contrary. Schnorr signatures are 64 bytes, so in situations like
lightning where the transaction form is deterministically derived, signing 100
extra transactions requires just 6400
On 10/20/23 9:25 PM, Peter Todd wrote:
On Fri, Oct 20, 2023 at 09:03:49PM -0400, Matt Corallo wrote:
What are anchor outputs used for other than increasing fees?
Because if we've pre-signed the full fee range, there is simply no need for
anchor outputs. Under any circumstance we can broadcas
On 10/20/23 8:15 PM, Peter Todd wrote:
On Fri, Oct 20, 2023 at 05:05:48PM -0400, Matt Corallo wrote:
Sadly this only is really viable for pre-anchor channels. With anchor
channels the attack can be performed by either side of the closure, as the
HTLCs are now, at max, only signed SIGHASH_SING
Sadly this only is really viable for pre-anchor channels. With anchor channels the attack can be
performed by either side of the closure, as the HTLCs are now, at max, only signed
SIGHASH_SINGLE|ANYONECANPAY, allowing you to add more inputs and perform this attack even as the
broadcaster.
I do
12:23 PM, Matt Morehouse wrote:
On Wed, Oct 18, 2023 at 12:34 AM Matt Corallo via bitcoin-dev
wrote:
There appears to be some confusion about this issue and the mitigations. To be
clear, the deployed
mitigations are not expected to fix this issue, its arguable if they provide
anything more t
There appears to be some confusion about this issue and the mitigations. To be clear, the deployed
mitigations are not expected to fix this issue, its arguable if they provide anything more than a PR
statement.
There are two discussed mitigations here - mempool scanning and transaction
re-sign
Hi Michael,While I don’t think forks of Core with an intent to drive consensus rule changes (or lack thereof) benefits the bitcoin system as the Bitcoin Core project stands today, if you want to build a nice full node wallet with lightning based on a fork of Core, there was code written to do this
The signature verifies for me, however the email was sent HTML and the signature only verifies in
plaintext, so I had to copy it into a text file. I've included the email as-verified below.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Due to last-minute issues (https://github.com/bitcoin/bit
On 9/17/22 2:14 AM, Anthony Towns wrote:
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 &q
Apologies for any typos, somewhat jet-lagged atm.
On 9/16/22 3:15 AM, Anthony Towns via bitcoin-dev wrote:
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
Still trying to make sure I understand this concern, let me know if I get this
all wrong.
On 4/22/22 10:25 AM, Russell O'Connor via bitcoin-dev wrote:
It's not the attackers *only choice to succeed*. If an attacker steals the hot key, then they have
the option to simply wait for the user to un
On 4/21/22 6:20 PM, David A. Harding wrote:
[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,
plu
On 4/22/22 9:28 AM, James O'Beirne wrote:
> There are at least three or four separate covenants designs that have
> been posted to this list, and I don't see why we're even remotely
> talking about a specific one as something to move forward with at
> this point.
To my knowledge none of t
On 4/21/22 3:28 PM, David A. Harding wrote:
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 co
On 4/21/22 11:06 AM, David A. Harding wrote:
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-worl
On 4/20/22 6:04 PM, David A. Harding via bitcoin-dev wrote:
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
This is great in theory, but I think it kinda misses *why* the complexity keeps creeping in. We
agree on (most of) the goals here, but the problem is the goals explicitly lead to the complexity,
its not some software engineering failure or imagination failure that leads to the complexity.
On 2/
> On Sep 13, 2021, at 21:56, Anthony Towns wrote:
> I'm not sure that's really the question you want answered?
Of course it is? I’d like to understand the initial thinking and design
analysis that went into this decision. That seems like an important question to
ask when seeking changes in an
> On Sep 13, 2021, at 05:30, Michael Folkson wrote:
>
>
>>
>> Can you explain the motivation for this? From where I sit, as far as I know,
>> I should basically be > a prime example of the target market for public
>> signet - someone developing bitcoin applications > with regular requireme
> On Sep 12, 2021, at 00:53, Anthony Towns wrote:
>
> On Thu, Sep 09, 2021 at 05:50:08PM -0700, Matt Corallo via bitcoin-dev wrote:
>>> AJ proposed to allow SigNet users to opt-out of reorgs in case they
>>> explicitly want to remain unaffected. This can be done by
Fwiw, your email client is broken and does not properly quote in the plaintext copy. I believe this
is a known gmail bug, but I'd recommend avoiding gmail's web interface for list posting :).
On 9/10/21 12:00, Michael Folkson wrote:
Huh? Why would the goal be to match mainnet? The goal, as I un
On 9/10/21 06:05, Michael Folkson wrote:
I see zero reason whatsoever to not simply reorg ~every block, or as often as
is practical. If users opt in to wanting to test with reorgs, they should be
able to test with reorgs, not wait a day to test with reorgs.
One of the goals of the default
On 9/7/21 09:07, 0xB10C via bitcoin-dev wrote:
Hello,
tl;dr: We want to make reorgs on SigNet a reality and are looking for
feedback on approach and parameters.
Awesome!
AJ proposed to allow SigNet users to opt-out of reorgs in case they
explicitly want to remain unaffected. This can be don
Thanks for taking the time to write this up!
To wax somewhat broadly here, I’m very excited about this as a direction for
bitcoin covenants. Other concrete proposals seem significantly more limited,
which worries me greatly. Further, this feels very “taproot-native” in a way
that encourages uti
If it weren't for the implications in changing standardness here, I think we should consider increasing the dust limit
instead.
The size of the UTXO set is a fundamental scalability constraint of the system. In fact, with proposals like
assume-utxo/background history sync it is arguably *the* f
I find this point to be incredibly important. Indeed I, like several others, have historically been concerned with
covenants in the unbounded form. However, as more and more research has been done in what they can accomplish, the
weighting of such arguments naturally has to be reduced. More impor
Alright, let's see...
Sorting by most recently updated...
https://github.com/bitcoin/bips/pulls?page=1&q=is%3Apr+is%3Aopen+sort%3Aupdated-asc+updated%3A%3E2021-01-01
#1104 has been updated nearly daily for the past many weeks. You commented 12 days ago saying "Concept NACK" (which
isn't a thing
On 4/25/21 17:00, Luke Dashjr wrote:
On Sunday 25 April 2021 20:29:44 Matt Corallo wrote:
If the BIP editor is deliberately refusing to accept changes which the
author's approval (which appears to be occurring here),
It isn't. I am triaging BIPs PRs the same as I have for years, and will get t
There appears to be some severe lack of understanding of the point of the BIP
process here.
The BIP process exists to be a place for those in the Bitcoin development community (which includes anyone who wishes to
participate in it!) to place specifications which may be important for others in t
What is preventing the BIP maintainership role from moving to a bot? It does seem like a bot should be able to do a fine
job given the explicit criteria (though ignoring obvious spam is often nice, its by no means a requirement).
Given recent events where humans haveacted like humans, it see
Probably worth noting, but while the coin toss was acceptable to many people as "who cares, just move on", the two
authors of actual code for the two proposals here also came to an agreement on a way forward, so its not like it was a
"coin toss to overrule everyone on 'the other side'".
On 4/8/
On 4/7/21 01:01, Rusty Russell via bitcoin-dev wrote:
Ryan Grant writes:
On Tue, Apr 6, 2021 at 11:58 PM Rusty Russell via bitcoin-dev
What ST is saying is that a strategy of avoiding unnecessary risk is
stronger than a strategy of brinkmanship when brinkmanship wasn't
our only option. Havi
I'm somewhat gobsmacked that this entire conversation hasn't included the word "market" in it at all. If there's one
thing we can all agree we learned from Segwit2x, BCH, BSV, BU, etc, its that, ultimately, the market decides. Not only
does the market decide, but there's lots of money to be made
On 3/15/21 23:44, Luke Dashjr wrote:
(To reiterate: I do not intend any of this as a NACK of Taproot.)
Frankly, then why parrot arguments you don't agree with in an already-tense discussion? I'm really not sure what there
is to gain by dredging up years-old since-settled debates except to c
ction.
Matt
On 3/15/21 19:01, Karl-Johan Alm via bitcoin-dev wrote:
On Tue, 16 Mar 2021 at 07:48, Matt Corallo via bitcoin-dev
wrote:
Overall, the tradeoffs here seem ludicrous, given that any QC issues in Bitcoin
need to be solved in another way, and
can't practically be solved by just
On Mon, Mar 15, 2021 at 3:06 PM Matt Corallo via bitcoin-dev <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
There have been many threads on this before, I'm not sure anything new has
been brought up here.
Matt
On 3/15/21 17:48, Luke Dashjr via bitcoin-dev wrot
There have been many threads on this before, I'm not sure anything new has been
brought up here.
Matt
On 3/15/21 17:48, Luke Dashjr via bitcoin-dev wrote:
I do not personally see this as a reason to NACK Taproot, but it has become
clear to me over the past week or so that many others are unawa
On 3/6/21 14:56, Michael Folkson wrote:
Hi Matt
> 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. Instead, a three month window is certainly long enough to organize and make
a lo
I don't think anyone is proposing anything to "prevent" other people from doing anything they wish. My understanding of
the goal of this proposal, itself, was to keep the community together by proposing a solution that was palatable to all.
My point was that I'm not sure that this proposal achiev
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. Instead, a three month window is certainly long enough to organize and make a
lot of noise around such an effort, given BIP 148 was organ
Replies inline. Several sections removed, where I basically agree.
On 3/4/21 08:47, Russell O'Connor wrote:
Appologies as I've rearranged your comments in my reply.
I agree with you. I also think we have plenty of evidence to proceed with taproot and could proceed with a PR for such
a flag day
On 3/3/21 14:08, Russell O'Connor via bitcoin-dev wrote:
While I support essentially any proposed taproot activation method, including a flag day activation, I think it is
premature to call BIP8 dead.
Even today, I still think that starting with BIP8 LOT=false is, generally speaking, consider
On 3/3/21 09:59, Anthony Towns wrote:
I think it would be worthwhile to also update getblocktemplate so that
miners signal uptake for something like three or four retarget periods
prior to activation, without that signalling having any consensus-level
effect. That should allow miners and busin
Glad you asked! Yes, your goal here is #4 on the list of goals I laid out at [1], which I referenced and specifically
addressed each of in the OP of this thread.
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html
On 2/28/21 15:19, Eric Voskuil wrote:
In the a
SPV mining has been curtailed somewhat to only apply for a brief period of time (based on public statements) since the
last time SPV mining caused a fork. Indeed, if you can make other miners mine on top of an invalid block, you can make
money by reducing the difficulty, but that is true as much
Note further that mandatory signaling isn't "just" a flag day - unlike a Taproot flag day (where miners running Bitcoin
Core unmodified today will not generate invalid blocks), a mandatory signaling flag day blatantly ignores goal (3) from
my original post - it results in any miner who has not ta
On 2/28/21 12:20, Luke Dashjr wrote:
On Sunday 28 February 2021 16:45:22 Matt Corallo via bitcoin-dev wrote:
Concept NACK. This still has the same problems BIP149 would have had, as I
just reminded in my last email to this ML:
1) Such a chain does not indicate activation at all, leaving it unre
As anyone reading this list is aware, there is significant debate around the activation method for the proposed Taproot
soft fork. So much so, and with so much conviction, that many individuals are committing themselves to running
incompatible consensus rules. Obviously, such commitments, were th
Forced-signaling, or any form of signaling, does not materially change whether a soft fork can be seen to be safe to
use. Pieter wrote a great post[1] some time ago that goes into depth about the security of soft forks, but, while miners
can help to avoid the risk of forks, they aren't the determ
> On Feb 22, 2021, at 05:16, Anthony Towns wrote:
>
> If a lockinontimeout=true node is requesting compact blocks from a
> lockinontimeout=false node during a chainsplit in the MUST_SIGNAL phase,
> I think that could result in a ban.
>
>> More importantly, nodes on both sides of the fork need
0PM -0500, Matt Corallo via bitcoin-dev wrote:
>> It was pointed out to me that this discussion is largely moot as the
>> software complexity for Bitcoin Core to ship an option like this is likely
>> not practical/what people would wish to see.
>> Bitcoin Core does not have i
internal node will then follow the dominant chain.
>>
>>
>> Regards,
>> ZmnSCPxj
>>
>>>
>>> Instead, the only practical way to ship such an option would be to treat
>>> it as a separate chain (the same way regtest,
>>> test
(off-list)
Your email client didn't thread correctly, so I'm not sure if you saw my responses to Adam's email, but note that there
is no such thing as "All that must be done" here - supporting multiple, different, consensus rules for a given chain is
a nontrivial undertaking in Bitcoin Core fro
practical way to ship such an option would be to treat it as a separate chain (the same way regtest,
testnet, and signet are treated), including its own separate datadir and the like.
Matt
On 2/19/21 09:13, Matt Corallo via bitcoin-dev wrote:
(Also in response to ZMN...)
Bitcoin Core has a
(Also in response to ZMN...)
Bitcoin Core has a long-standing policy of not shipping options which shoot
yourself in the foot. I’d be very disappointed if that changed now. People are
of course more than welcome to run such software themselves, but I anticipate
the loud minority on Twitter and
t time, so if I'm
missing something please say so. But from my point of view, we can't treat all soft forks as equal.
Keagan
On Thu, Feb 18, 2021 at 7:43 AM Matt Corallo via bitcoin-dev <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
We've had several soft
cide, whatever" argument) or a
different consensus, we'd be much, much better off not having Taproot at all.
Matt
On 2/18/21 09:53, Matt Corallo via bitcoin-dev wrote:
You say "short term PR", I say "risking millions of user dollars".
On 2/18/21 09:51, Michael Folkso
You say "short term PR", I say "risking millions of user dollars".
On 2/18/21 09:51, Michael Folkson wrote:
> getting unlucky and hitting a 4-block reorg that happens to include a double-spend and some PR around an exchange
losing millions would be worse than having Taproot is good.
We are at
We've had several softforks in Bitcoin which, through the course of their activation, had a several-block reorg. That
should be indication enough that we need to very carefully consider activation to ensure we reduce the risk of that as
much as absolutely possible. Again, while I think Taproot is
If the eventual outcome is that different implementations (that have material
*transaction processing* userbases, and I’m not sure to what extent that’s true
with Knots) ship different consensus rules, we should stop here and not
activate Taproot. Seriously.
Bitcoin is a consensus system. The a
Bitcoin is a consensus system. Please let’s not jump to (or even consider)
options that discourage consensus. We all laughed at (and later academics
researched showed severe deficiencies in) Bitcoin XT’s “emergent consensus”
nonsense, why should we start doing things along that line in Bitcoin?
So we’d kill two birds with one stone if all bloom support was dropped. As far
as I understand, precomputed filters are now provided via p2p connections as
well.
Matt
> On Jan 14, 2021, at 00:33, Anthony Towns wrote:
>
> On Wed, Jan 13, 2021 at 01:40:03AM -0500, Matt Corallo via bi
Out of curiosity, was the interaction between fRelay and bloom disabling ever
specified? ie if you aren’t allowed to enable bloom filters on a connection due
to resource constraints/new limits, is it ever possible to “set” fRelay later?
Matt
> On Jan 6, 2021, at 11:35, Suhas Daftuar via bitcoin
[resent with correct source, sorry Michael, stupid Apple]
Yes, a “default” signet that regularly reorgs a block or two all the time and is “compatible” with testnet but a faster
block target (eg so that it is trivial to mine but still has PoW) and freshly-seeded genesis would be a massive step-u
Hmm, could that not be accomplished by simply building this into new messages? eg, send "betterprotocol", if you see a
verack and no "betterprotocol" from your peer, send "worseprotocol" before you send a "verack".
Matt
On 8/21/20 5:17 PM, Jeremy wrote:
As for an example of where you'd want mul
This seems to be pretty overengineered. Do you have a specific use-case in mind for anything more than simply continuing
the pattern we've been using of sending a message indicating support for a given feature? If we find some in the future,
we could deploy something like this, though the current
Sure, we could do a new message for negotiation, but there doesn’t seem to be a
lot of reason for it - using the same namespace for negotiation seems fine too.
In any case, this is one of those things that doesn’t matter in the slightest,
and if one person volunteers to write a BIP and code, no
message(s).
FWIW, bip37 did this poorly, adding a feature field to the version message,
resulting in bip60. Due to this design, older protocol-validating clients were
broken. In this case it was message length that was presumed to not be
validated.
e
On Aug 18, 2020, at 07:59, Matt Corallo via
e
On Aug 18, 2020, at 07:59, Matt Corallo via bitcoin-dev
wrote:
This sounds like a great idea!
Bitcoin is no longer a homogeneous network of one client - it is many, with different features implemented in each.
The Bitcoin protocol hasn't (fully) evolved to capture that reality. Init
This sounds like a great idea!
Bitcoin is no longer a homogeneous network of one client - it is many, with different features implemented in each. The
Bitcoin protocol hasn't (fully) evolved to capture that reality. Initially the Bitcoin protocol had a simple numerical
version field, but that i
with high total fee, etc.
On Thu, Aug 6, 2020 at 5:59 PM Matt Corallo via bitcoin-dev <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
In general, SIGHASH_NOINPUT makes these issues much, much simpler to
address, but only if we assume that nodes can
somehow be "smart
Yep! That is the attack I had in mind - just in general any time you have a
non-relative time limit (ie an HTLC) for
confirmation, relay attacks become critical and its no longer just about
revocation (which is fine when your time limit
is CSV-based).
In general, SIGHASH_NOINPUT makes these issu
Hmm, apologies that little context was provided - this was meant in the context
of the current crop of relay-based attacks that have been discovered. As we
learned in those contexts, “just handle it when it confirms” doesn’t provide
the types of guarantees we were hoping for as placing commitmen
While I admit I haven’t analyzed the feasibility, I want to throw one
additional design consideration into the ring.
Namely, it would ideally be trivial, at the p2p protocol layer, to relay a
transaction to a full node without knowing exactly which input transaction that
full node has in its me
Thanks Anthony for this writeup!
I find it incredibly disappointing that the idea of naive flag day fork
activation is being seriously discussed in the
form of BIP 9. Activation of forks is not only about the included changes but
also around the culture of how changes to
Bitcoin should be and ar
Given transaction relay delays and a network topology that is rather
transparent if you look closely enough, I think this is very real and very
practical (double-digit % success rate, at least, with some trial and error
probably 50+). That said, we all also probably know most of the people who k
On 4/23/20 8:46 AM, ZmnSCPxj wrote:
>>> - Miners, being economically rational, accept this proposal and include
>>> this in a block.
>>>
>>> The proposal by Matt is then:
>>>
>>> - The hashlock branch should instead be:
>>> - B and C must agree, and show the preimage of some hash H (hashl
Great summary, a few notes inline.
> On Apr 22, 2020, at 21:50, ZmnSCPxj wrote:
>
> Good morning lists et al,
>
> Let me try to summarize things a little:
>
> * Suppose we have a forwarding payment A->B->C.
> * Suppose B does not want to maintain a mempool and is running in
> `blocksonly` mo
On 4/22/20 7:27 PM, Olaoluwa Osuntokun wrote:
>
>> Indeed, that is what I’m suggesting
>
> Gotcha, if this is indeed what you're suggesting (all HTLC spends are now
> 2-of-2 multi-sig), then I think the modifications to the state machine I
> sketched out in an earlier email are required. An exa
> On Apr 22, 2020, at 16:13, Olaoluwa Osuntokun wrote:
>
> > Hmm, maybe the proposal wasn't clear. The idea isn't to add signatures to
> > braodcasted transactions, but instead to CPFP a maybe-broadcasted
> > transaction by sending a transaction which spends it and seeing if it is
> > accepted
Hmm, that's an interesting suggestion, it definitely raises the bar for attack
execution rather significantly. Because lightning (and other second-layer
systems) already relies heavily on uncensored access to blockchain data, its
reasonable to extend the "if you don't have enough blocks, aggres
On 4/22/20 12:12 AM, ZmnSCPxj wrote:
> Good morning Matt, and list,
>
>
>
>> RBF Pinning HTLC Transactions (aka "Oh, wait, I can steal funds, how,
>> now?")
>> =
>>
>> You'll note that in the discussion of RBF pinning we were pretty broad,
>> and that
A few replies inline.
On 4/22/20 12:13 AM, Olaoluwa Osuntokun wrote:
> Hi Matt,
>
>
>> While this is somewhat unintuitive, there are any number of good anti-DoS
>> reasons for this, eg:
>
> None of these really strikes me as "good" reasons for this limitation, which
> is at the root of this iss
[Hi bitcoin-dev, in lightning-land we recently discovered some quite
frustrating issues which I thought may merit
broader discussion]
While reviewing the new anchor outputs spec [1] last week, I discovered it
introduced a rather nasty ability for a user
to use RBF Pinning to steal in-flight HTLC
Responding purely to one point as this may be sufficient to clear up
lots of discussion:
On 2/9/20 8:19 PM, Bryan Bishop via bitcoin-dev wrote:
> Is Taproot just a probability assumption about the frequency and
> likelihood of
> the signature case over the script case? Is this a good assumption?
The orphan pool has nontrivial denial of service properties around transaction
validation. In general, I think the goal has been to reduce/remove it, not the
other way around. In any case, this is likely the wrong forum for
software-level discussion of Bitcoin Core. For that, you probably want t
ony Towns wrote:
> On Fri, Jan 10, 2020 at 09:30:09PM +, Matt Corallo via bitcoin-dev wrote:
>> 1) a standard BIP 9 deployment with a one-year time horizon for
>> activation with 95% miner readiness,
>> 2) in the case that no activation occurs within a year, a six month
>>
Good thing no one is proposing a naive BIP 9 approach :). I'll note that
BIP 9 has been fairly robust (spy-mining issues notwithstanding, which
we believe are at least largely solved in the wild) in terms of safety,
though I noted extensively in the first mail that it failed in terms of
misundersta
lean" split.
>
> I assume many people won't like this, but I really think we should
> consider how users should ideally resist an unwanted change, even if
> the proponents had the best intentions in mind, there may be
> legitimate reasons to resist it that they may not have
There are a series of soft-fork designs which have recently been making
good progress towards implementation and future adoption. However, for
various reasons, activation methods therefor have gotten limited
discussion. I'd like to reopen that discussion here.
It is likely worth revisiting the goa
There is effort ongoing to upgrade the Bitcoin P2P protocol to support other
address types, including onion v3. There are various posts on this ML under the
title “addrv2”. Further review and contributions to that effort is, as always,
welcome.
> On Nov 17, 2019, at 00:05, Mr. Lee Chiffre via b
Seems good to me, though I'm curious if we have any (even vaguely)
immediate need for non-32/20-byte Segwit outputs? It seems to me this
can be resolved by just limiting the size of bech32 outputs and calling
it a day - adding yet another address format has very significant
ecosystem costs, and if
Given the issue is in the address format, not the consensus/standardness layer,
it does seem somewhat strange to jump to addressing it with a
consensus/standardness fix. Maybe the ship has sailed, but for the sake of
considering all our options, we could also redefine bech32 to not allow such
a
I don’te see how? Let’s imagine Party A has two spendable outputs, now they
stuff the package size on one of their spendable outlets until it is right at
the limit, add one more on their other output (to meet the Carve-Out), and now
Party B can’t do anything.
> On Oct 24, 2019, at 21:05, Johan
I may be missing something, but I'm not sure how this changes anything?
If you have a commitment transaction, you always need at least, and
exactly, one non-CSV output per party. The fact that there is a size
limitation on the transaction that spends for carve-out purposes only
effects how many ot
Indeed, Signet is no less (or more) Bitcoin than a seed format or BIP 32. It’s
“not Bitcoin” but it’s certainly “interoperability for how to build good
testing for Bitcoin”.
> On Oct 14, 2019, at 19:55, Karl-Johan Alm via bitcoin-dev
> wrote:
>
> Hello,
>
> The pull request to the bips repo
ven a rational justification for this change.
>
> Requiring SPV wallets to communicate with trusted nodes is centralization,
> and breaking functionality and implementations that enable this without a
> thoroughly researched rationale is highly suspect.
>
>> On Jul 2
This conversation went off the rails somewhat. I don't think there's any
immediate risk of NODE_BLOOM peers being unavailable. This is a defaults
change, not a removal of the code to serve BIP 37 peers (nor would I suggest
removing said code while people still want to use them - the maintenance
Hey Andreas,
I think maybe some of the comments here were misunderstood - I don't
anticipate that most people will change their defaults, indeed, but
given the general upgrade cycles we've seen on the network over the
entire course of Bitcoin's history, there's little reason to believe
that many n
Just a quick heads-up for those watching the list who may be using it -
in the next Bitcoin Core release bloom filter serving will be turned off
by default. This has been a long time coming, it's been an option for
many releases and has been a well-known DoS vector for some time.
As other DoS vecto
1 - 100 of 238 matches
Mail list logo
