Re: [bitcoin-dev] A summary list of all concerns related to not rising the block size
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Geir, In the scenario below, you argue that the current 1MB limit would lead to "constantly full" blocks. If the limit is increased to say 1.6GB then a government or banking group may choose to utilize 1.5GB of the capacity of each block (and pay fees or not) for their settlement network. Then how did upping the blocksize remedy anything? Or is this use-case not plausible? I would like to ask you, or anyone on the list: when we say that mining secures the network, what does that mean? On 08/14/2015 05:01 AM, Geir Harald Hansen via bitcoin-dev wrote: > 3) A few more people begin using bitcoin. Bitcoin buckles and > dies. > > - Something happens a few months from now causing an influx of new > users and more transactions. - Blocks are constantly full. - A > backlog of transactions keeps growing indefinitely. - At first > people say "bitcoin is slow". After a while they say "bitcoin > doesn't work". - Changing the hard limit on block size requires a > fork and takes too long. - As bitcoin no longer works people stop > using it. - Bitcoin lives out the last of its days in the > backwaters of the internet with only 5 users. They keep telling > people "we increased the block size now". Unfortunately noone is > listening anymore. - People laugh at you and say "I told you that > buttcoin thing was doomed to fail. After all it wasn't real > money." > > If the hard limit had been increased earlier then mining pools > would have been able to react quickly by upping their own soft > limit. But this was not the case and so ended Bitcoin. > > So in summary: > > By increasing the block size limit you run the risk of: - The > transaction fee market takes a little longer to develop. By not > increasing the limit you run the risk of: - Bitcoin dies. The end. > > Transaction fees should not be the main topic of this discussion, > and probably not even a part of it at all. That seems outright > irresponsible to me. > > Regards, Geir H. Hansen, Bitminter mining pool > > On 12.08.2015 11:59, Jorge Timón via bitcoin-dev wrote: >> I believe all concerns I've read can be classified in the >> following groups: >> >>> 1) Potential indirect consequence of rising fees. >> >> - Lowest fee transactions (currently free transactions) will >> become more unreliable. - People will migrate to competing >> systems (PoW altcoins) with lower fees. >> >>> 2) Software problem independent of a concrete block size that >>> needs to be solved anyway, often specific to Bitcoin Core (ie >>> other implementations, say libbitcoin may not necessarily share >>> these problems). >> >> - Bitcoin Core's mempool is unbounded in size and can make the >> program crash by using too much memory. - There's no good way to >> increase the fee of a transaction that is taking too long to be >> mined without the "double spending" transaction with the higher >> fee being blocked by most nodes which follow Bitcoin Core's >> default policy for conflicting spends replacements (aka "first >> seen" replacement policy). >> >> I have started with the 3 concerns that I read more often, but >> please suggest more concerns for these categories and suggest >> other categories if you think there's more. >> ___ bitcoin-dev >> mailing list bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > > ___ bitcoin-dev mailing > list bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVzVHWAAoJEGwAhlQc8H1myaoH+QFo+eTqPqMps/h/Lt5P4Ker UIyCbouatdrRnKqJlpa+dy70+nK+nkz6fizXLC8fuWFDLPQ2uk1cUnp7FPcJ+f6L LdGiUktcF/osbA5DW/Xt1DQnClnfbR04oH3+l5ouwhTG2FL8018RQKTAZXYaQafE /GUzXBZt+dxpENE2ZE0YDORcm62cysFB8KiqS7NmrNC3sig/Bnw0k8x8y745LcSO j/icLJ/zlSVhtceb8AnSg5bC2xhKXrTsGQBfr4foDh78n0+xcbEQO/6xc29rydeB l8VwzqCwyFZScM/4lhgYHgEB2KE3MecGNy0vh7jKVqh9lQUMlWtpHRy/Nony5mA= =MEzL -END PGP SIGNATURE- ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime
On Thu, Aug 13, 2015 at 4:42 PM, Joseph Poon via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I haven't tested the details of this, but is there another bit available > for use in the future for the relative blockheight? > > I strongly believe that Lightning needs mitigations for a systemic > supervillan attack which attemps to flood the network with transactions, > which can hypothetically be mitigated with something like a timestop > bit (as originally suggested by gmaxwell). > This proposal includes no such provision. Since we talked about it, I spent considerable time thinking about the supposed risk and proposed mitigations. I'm frankly not convinced that it is a risk of high enough credibility to worry about, or if it is that a protocol-level complication is worth doing. The scenario as I understand it is a hub turns evil and tries to cheat every single one of its users out of their bonds. Normally a lightning user is protected form such behavior because they have time to broadcast their own transactions spending part or all of the balance as fees. Therefore because of the threat of mutually assured destruction, the optimal outcome is to be an honest participant. But, the argument goes, the hub has many channels with many different people closing at the same time. So if the hub tries to cheat all of them at once by DoS'ing the network, it can do so and spend more in fees than any one participant stands to lose. My issue with this is that users don't act alone -- users can be assured that other users will react, and all of them together have enough coins to burn to make the attack unprofitable. The hub-cheats-many-users case really is the same as the hub-cheats-one-user case if the users act out their role in unison, which they don't have to coordinate to do. Other than that, even if you are still concerned about that scenario, I'm not sure timestop is the appropriate solution. A timestop is a protocol-level complication that is not trivial to implement, indeed I'm not even sure there is a way to implement it at all -- how do you differentiate in consensus code a DoS attack from regular old blocks filling up? And if you could, why add further complication to the consensus protocol? A simpler solution to me seems to be outsourcing the response to an attack to a third party, or otherwise engineering ways for users to respond-by-default even if their wallet is offline, or otherwise assuring sufficient coordination in the event of a bad hub. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime
Very cool! This will certainly help make Lightning Network testable on the main-chain and permit channels to remain open indefinitely. I'm looking forward to it. On Thu, Aug 13, 2015 at 12:06:44PM +0100, Btc Drak via bitcoin-dev wrote: > // Note that unlike CHECKLOCKTIMEVERIFY we do not need to > // accept 5-byte bignums since any value greater than or > // equal to SEQUENCE_THRESHOLD (= 1 << 31) will be rejected > // anyway. This limitation just happens to coincide with > // CScriptNum's default 4-byte limit with an explicit sign > // bit. I haven't tested the details of this, but is there another bit available for use in the future for the relative blockheight? I strongly believe that Lightning needs mitigations for a systemic supervillan attack which attemps to flood the network with transactions, which can hypothetically be mitigated with something like a timestop bit (as originally suggested by gmaxwell). Summary: If a block is flagged as timestopped (whether automatically or by vote or other mechanism), then an auxillary blockheigh is frozen and does not increment. This auxillary blockheight is only used for accounting in timestopped height computation (and isn't used for anything else). So as the real blockheight increments, the auxillary blockheight can sometimes stop and stay the same. If a transaction has a timestop bit enabled, then the transaction's OP_CSV relative height is dependent upon the auxillary height, not the real block height. This allows for a large backlog of transactions which must occur before a particular (relative) block height to enter into the blockchain. I'm not sure if it's out of scope, but it could make sense to consider the possibility for additional state(s) with relative height computation today. Ideally, there'd be some kind of "version" byte which can be recontextualized into something later, but I don't know how that could cleanly fit into the data structure/code. -- Joseph Poon ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] A summary list of all concerns related to not rising the block size
3) A few more people begin using bitcoin. Bitcoin buckles and dies. - Something happens a few months from now causing an influx of new users and more transactions. - Blocks are constantly full. - A backlog of transactions keeps growing indefinitely. - At first people say "bitcoin is slow". After a while they say "bitcoin doesn't work". - Changing the hard limit on block size requires a fork and takes too long. - As bitcoin no longer works people stop using it. - Bitcoin lives out the last of its days in the backwaters of the internet with only 5 users. They keep telling people "we increased the block size now". Unfortunately noone is listening anymore. - People laugh at you and say "I told you that buttcoin thing was doomed to fail. After all it wasn't real money." If the hard limit had been increased earlier then mining pools would have been able to react quickly by upping their own soft limit. But this was not the case and so ended Bitcoin. So in summary: By increasing the block size limit you run the risk of: - The transaction fee market takes a little longer to develop. By not increasing the limit you run the risk of: - Bitcoin dies. The end. Transaction fees should not be the main topic of this discussion, and probably not even a part of it at all. That seems outright irresponsible to me. Regards, Geir H. Hansen, Bitminter mining pool On 12.08.2015 11:59, Jorge Timón via bitcoin-dev wrote: > I believe all concerns I've read can be classified in the following groups: > >> 1) Potential indirect consequence of rising fees. > > - Lowest fee transactions (currently free transactions) will become > more unreliable. > - People will migrate to competing systems (PoW altcoins) with lower fees. > >> 2) Software problem independent of a concrete block size that needs to >> be solved anyway, often specific to Bitcoin Core (ie other >> implementations, say libbitcoin may not necessarily share these >> problems). > > - Bitcoin Core's mempool is unbounded in size and can make the program > crash by using too much memory. > - There's no good way to increase the fee of a transaction that is > taking too long to be mined without the "double spending" transaction > with the higher fee being blocked by most nodes which follow Bitcoin > Core's default policy for conflicting spends replacements (aka "first > seen" replacement policy). > > I have started with the 3 concerns that I read more often, but please > suggest more concerns for these categories and suggest other > categories if you think there's more. > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime
On Thu, Aug 13, 2015 at 6:12 PM, Mark Friedenbach wrote: > As per the rules of BIP 1, I hereby request that the BIP editor please > assign an official number to this work. The idea has been discussed before > on the bitcoin-dev mailing list: > > http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008452.html > > And a reference implementation is available here: > > https://github.com/maaku/bitcoin/tree/checksequenceverify I think it's important to allow some time for discussion with the actual proposed text up; as understandings can shift significantly. :) Btcdrak already asked me for numbers prior to posting text at all and I asked him to post text... ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime
As per the rules of BIP 1, I hereby request that the BIP editor please
assign an official number to this work. The idea has been discussed before
on the bitcoin-dev mailing list:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008452.html
And a reference implementation is available here:
https://github.com/maaku/bitcoin/tree/checksequenceverify
On Thu, Aug 13, 2015 at 4:06 AM, Btc Drak via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I have written the following draft BIP for a new opcode
> CHECKSEQUENCEVERIFY by Mark Friedenbach, which introduces a form of
> relative-locktime to Bitcoin's scripting language.
>
>
> https://github.com/btcdrak/bips/blob/bip-checksequenceverify/bip-csv.mediawiki
>
>
> BIP: XX
> Title: CHECKSEQUENCEVERIFY
> Authors: BtcDrak
>Mark Friedenbach
> Status: Draft
> Type: Standards Track
> Created: 2015-08-10
>
>
> ==Abstract==
>
> This BIP describes a new opcode (CHECKSEQUENCEVERIFY) for the Bitcoin
> scripting system that in combination with BIP 68 allows execution
> pathways of a script to be restricted based on the age of the output
> being spent.
>
>
> ==Summary==
>
> CHECKSEQUENCEVERIFY redefines the existing NOP3 opcode. When executed
> it compares the top item on the stack to the inverse of the nSequence
> field of the transaction input containing the scriptSig. If the
> inverse of nSequence is less than the sequence threshold (1 << 31),
> the transaction version is greater than or equal to 2, and the top
> item on the stack is less than or equal to the inverted nSequence,
> script evaluation continues as though a NOP was executed. Otherwise
> the script fails immediately.
>
> BIP 68's redefinition of nSequence prevents a non-final transaction
> from being selected for inclusion in a block until the corresponding
> input has reached the specified age, as measured in block heiht or
> block time. By comparing the argument to CHECKSEQUENCEVERIFY against
> the nSequence field, we indirectly verify a desired minimum age of the
> the output being spent; until that relative age has been reached any
> script execution pathway including the CHECKSEQUENCEVERIFY will fail
> to validate, causing the transaction not to be selected for inclusion
> in a block.
>
>
> ==Motivation==
>
> BIP 68 repurposes the transaction nSequence field meaning by giving
> sequence numbers new consensus-enforced semantics as a relative
> lock-time. However, there is no way to build Bitcoin scripts to make
> decisions based on this field.
>
> By making the nSequence field accessible to script, it becomes
> possible to construct code pathways that only become accessible some
> minimum time after proof-of-publication. This enables a wide variety
> of applications in phased protocols such as escrow, payment channels,
> or bidirectional pegs.
>
>
> ==Specification==
>
> Refer to the reference implementation, reproduced below, for the precise
> semantics and detailed rationale for those semantics.
>
>
> case OP_NOP3:
> {
> if (!(flags & SCRIPT_VERIFY_CHECKSEQUENCEVERIFY)) {
> // not enabled; treat as a NOP3
> if (flags & SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS) {
> return set_error(serror,
> SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS);
> }
> break;
> }
>
> if (stack.size() < 1)
> return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
>
> // Note that unlike CHECKLOCKTIMEVERIFY we do not need to
> // accept 5-byte bignums since any value greater than or
> // equal to SEQUENCE_THRESHOLD (= 1 << 31) will be rejected
> // anyway. This limitation just happens to coincide with
> // CScriptNum's default 4-byte limit with an explicit sign
> // bit.
> //
> // This means there is a maximum relative lock time of 52
> // years, even though the nSequence field in transactions
> // themselves is uint32_t and could allow a relative lock
> // time of up to 120 years.
> const CScriptNum nInvSequence(stacktop(-1), fRequireMinimal);
>
> // In the rare event that the argument may be < 0 due to
> // some arithmetic being done first, you can always use
> // 0 MAX CHECKSEQUENCEVERIFY.
> if (nInvSequence < 0)
> return set_error(serror, SCRIPT_ERR_NEGATIVE_LOCKTIME);
>
> // Actually compare the specified inverse sequence number
> // with the input.
> if (!CheckSequence(nInvSequence))
> return set_error(serror, SCRIPT_ERR_UNSATISFIED_LOCKTIME);
>
> break;
> }
>
> bool CheckSequence(const CScriptNum& nInvSequence) const
> {
> int64_t txToInvSequence;
>
> // Fail under all circumstances if the transaction's version
> // number is not set high enough to enable enforced sequence
> // number rules.
> if (txTo->nVersion < 2)
> r
Re: [bitcoin-dev] A summary list of all concerns related to not rising the block size
> On Aug 13, 2015, at 2:52 AM, Ashley Holman via bitcoin-dev > wrote: > > A concern I have is about security (hash rate) as a function of block size. > > I am assuming that hash rate is correlated with revenue from mining. > > Total revenue from fees as a function of block size should be a curve. On > one extreme of the curve, if blocks are too big, fee revenue tends towards 0 > as there is no competition for block space. This isn’t necessarily true. Every miner has its own mining policy. If they choose to delay including transactions proportional to their fee + first seen, then you create a time based fee market. Want quick confirmation? Pay a high fee. Don’t care that much? Pay a low fee (and anywhere in between). This market would work just fine even if block capacity was unbounded. jp signature.asc Description: Message signed with OpenPGP using GPGMail ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime (Btc Drak)
On August 13, 2015 7:34:03 PM GMT+03:00, Nicolas Dorier via bitcoin-dev wrote: >Would be wonderful to have this pushed together with CLTV and BIP68. >If BIP68 get pushed in the next fork, this CSV is a no brainer. > >Was there a competing RCLTV implementation somewhere that did not >depend on >BIP68 for information ? I don't manage to find it. I think all such competing proposals are dropped because this seemed like a better idea. Feel free to revive one/come up with one, though. Matt ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime (Btc Drak)
Would be wonderful to have this pushed together with CLTV and BIP68. If BIP68 get pushed in the next fork, this CSV is a no brainer. Was there a competing RCLTV implementation somewhere that did not depend on BIP68 for information ? I don't manage to find it. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime
I have written the following draft BIP for a new opcode
CHECKSEQUENCEVERIFY by Mark Friedenbach, which introduces a form of
relative-locktime to Bitcoin's scripting language.
https://github.com/btcdrak/bips/blob/bip-checksequenceverify/bip-csv.mediawiki
BIP: XX
Title: CHECKSEQUENCEVERIFY
Authors: BtcDrak
Mark Friedenbach
Status: Draft
Type: Standards Track
Created: 2015-08-10
==Abstract==
This BIP describes a new opcode (CHECKSEQUENCEVERIFY) for the Bitcoin
scripting system that in combination with BIP 68 allows execution
pathways of a script to be restricted based on the age of the output
being spent.
==Summary==
CHECKSEQUENCEVERIFY redefines the existing NOP3 opcode. When executed
it compares the top item on the stack to the inverse of the nSequence
field of the transaction input containing the scriptSig. If the
inverse of nSequence is less than the sequence threshold (1 << 31),
the transaction version is greater than or equal to 2, and the top
item on the stack is less than or equal to the inverted nSequence,
script evaluation continues as though a NOP was executed. Otherwise
the script fails immediately.
BIP 68's redefinition of nSequence prevents a non-final transaction
from being selected for inclusion in a block until the corresponding
input has reached the specified age, as measured in block heiht or
block time. By comparing the argument to CHECKSEQUENCEVERIFY against
the nSequence field, we indirectly verify a desired minimum age of the
the output being spent; until that relative age has been reached any
script execution pathway including the CHECKSEQUENCEVERIFY will fail
to validate, causing the transaction not to be selected for inclusion
in a block.
==Motivation==
BIP 68 repurposes the transaction nSequence field meaning by giving
sequence numbers new consensus-enforced semantics as a relative
lock-time. However, there is no way to build Bitcoin scripts to make
decisions based on this field.
By making the nSequence field accessible to script, it becomes
possible to construct code pathways that only become accessible some
minimum time after proof-of-publication. This enables a wide variety
of applications in phased protocols such as escrow, payment channels,
or bidirectional pegs.
==Specification==
Refer to the reference implementation, reproduced below, for the precise
semantics and detailed rationale for those semantics.
case OP_NOP3:
{
if (!(flags & SCRIPT_VERIFY_CHECKSEQUENCEVERIFY)) {
// not enabled; treat as a NOP3
if (flags & SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS) {
return set_error(serror, SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS);
}
break;
}
if (stack.size() < 1)
return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
// Note that unlike CHECKLOCKTIMEVERIFY we do not need to
// accept 5-byte bignums since any value greater than or
// equal to SEQUENCE_THRESHOLD (= 1 << 31) will be rejected
// anyway. This limitation just happens to coincide with
// CScriptNum's default 4-byte limit with an explicit sign
// bit.
//
// This means there is a maximum relative lock time of 52
// years, even though the nSequence field in transactions
// themselves is uint32_t and could allow a relative lock
// time of up to 120 years.
const CScriptNum nInvSequence(stacktop(-1), fRequireMinimal);
// In the rare event that the argument may be < 0 due to
// some arithmetic being done first, you can always use
// 0 MAX CHECKSEQUENCEVERIFY.
if (nInvSequence < 0)
return set_error(serror, SCRIPT_ERR_NEGATIVE_LOCKTIME);
// Actually compare the specified inverse sequence number
// with the input.
if (!CheckSequence(nInvSequence))
return set_error(serror, SCRIPT_ERR_UNSATISFIED_LOCKTIME);
break;
}
bool CheckSequence(const CScriptNum& nInvSequence) const
{
int64_t txToInvSequence;
// Fail under all circumstances if the transaction's version
// number is not set high enough to enable enforced sequence
// number rules.
if (txTo->nVersion < 2)
return false;
// Sequence number must be inverted to convert it into a
// relative lock-time.
txToInvSequence = (int64_t)~txTo->vin[nIn].nSequence;
// Sequence numbers under SEQUENCE_THRESHOLD are not consensus
// constrained.
if (txToInvSequence >= SEQUENCE_THRESHOLD)
return false;
// There are two types of relative lock-time: lock-by-
// blockheight and lock-by-blocktime, distinguished by
// whether txToInvSequence < LOCKTIME_THRESHOLD.
//
// We want to compare apples to apples, so fail the script
// unless the type of lock-time being tested is the same as
//
Re: [bitcoin-dev] A summary list of all concerns related to not rising the block size
A concern I have is about security (hash rate) as a function of block size. I am assuming that hash rate is correlated with revenue from mining. Total revenue from fees as a function of block size should be a curve. On one extreme of the curve, if blocks are too big, fee revenue tends towards 0 as there is no competition for block space. At the other extreme, if blocks are too small, fee revenue is limited only to what the most valuable use case(s) can afford. Somewhere in the middle there should be a sweet spot where fee revenue is maximised. It's not a static curve though, it should change as demand for block space changes. Failing to scale the block size as demand grows might be forfeiting potential miner revenue and hence security. (I don't think that should be a primary concern though since decentralisation should come first, but I'm just pointing it out as a secondary concern). On Wed, Aug 12, 2015 at 7:59 PM, Jorge Timón < bitcoin-dev@lists.linuxfoundation.org> wrote: > I believe all concerns I've read can be classified in the following groups: > > > 1) Potential indirect consequence of rising fees. > > - Lowest fee transactions (currently free transactions) will become > more unreliable. > - People will migrate to competing systems (PoW altcoins) with lower fees. > > > 2) Software problem independent of a concrete block size that needs to > > be solved anyway, often specific to Bitcoin Core (ie other > > implementations, say libbitcoin may not necessarily share these > > problems). > > - Bitcoin Core's mempool is unbounded in size and can make the program > crash by using too much memory. > - There's no good way to increase the fee of a transaction that is > taking too long to be mined without the "double spending" transaction > with the higher fee being blocked by most nodes which follow Bitcoin > Core's default policy for conflicting spends replacements (aka "first > seen" replacement policy). > > I have started with the 3 concerns that I read more often, but please > suggest more concerns for these categories and suggest other > categories if you think there's more. > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
