Re: [bitcoin-dev] Few questions regarding ListTransaction

[Maksim Solovjov via bitcoin-dev]

OK.

Thank you guys for clarification.

On Wed, Apr 11, 2018 at 1:00 PM, Karl-Johan Alm via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Thanks for clarifying!
>
> On Wed, Apr 11, 2018 at 6:48 PM, ZmnSCPxj  wrote:
> > Good morning Karl-Johan Alm,
> >
> > To clarify:
> >
> > Nothing prevents a miner from completely ignoring nSequence when putting
> transactions in blocks.
> >
> > Unconfirmed transactions are, by definition, not recorded in blocks.  So
> if there is a transaction 0xFFF nSequence and fee 1000 satoshi, and
> another conflicting transaction 0xFFF nSequence and fee 1
> satoshi, miners can include the latter one even if the first one came to
> their knowledge first, regardless nSequence.
> >
> > Thus, in the end "full replace-by-fee", where nSequence is IGNORED for
> purposes of replace-by-fee, is expected to become the norm, and we should
> really be designing our wallets and so on so that we only trust
> transactions that have confirmations.
> >
> > The "nSequence=0x means opt-OUT of RBF" convention is only
> followed by fullnodes running standard bitcoind.  Nothing prevents miners
> from running patched bitcoind that ignores this rule, and connecting with
> similar peers who also ignore this rule.
> >
> > Regards,
> > ZmnSCPxj
> >
> >
> > Sent with ProtonMail Secure Email.
> >
> > ‐‐‐ Original Message ‐‐‐
> >
> > On April 11, 2018 5:37 PM, Peter Todd via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> >> On Wed, Apr 11, 2018 at 05:10:43PM +0900, Karl-Johan Alm wrote:
> >>
> >> > On Wed, Apr 11, 2018 at 4:52 PM, Peter Todd p...@petertodd.org wrote:
> >> >
> >> > > Or via full replace-by-fee, which appears to be used by a
> significant minority
> >> > >
> >> > > of miners:
> >> >
> >> > I was of the impression that final transactions (sequence=0x)
> >> >
> >> > cannot be RBF'd.
> >>
> >> My full-replace-by-fee tree ignores that. It also does preferential
> peering to
> >>
> >> ensure it's well connected with likewise peers, and thus the whole
> network.
> >>
> >>
> >> 
> 
> ---
> >>
> >> https://petertodd.org 'peter'[:-1]@petertodd.org
> >>
> >> 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
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Few questions regarding ListTransaction

[ZmnSCPxj via bitcoin-dev]

Good morning Karl-Johan Alm,

To clarify:

Nothing prevents a miner from completely ignoring nSequence when putting 
transactions in blocks.

Unconfirmed transactions are, by definition, not recorded in blocks.  So if 
there is a transaction 0xFFF nSequence and fee 1000 satoshi, and another 
conflicting transaction 0xFFF nSequence and fee 1 satoshi, miners 
can include the latter one even if the first one came to their knowledge first, 
regardless nSequence.

Thus, in the end "full replace-by-fee", where nSequence is IGNORED for purposes 
of replace-by-fee, is expected to become the norm, and we should really be 
designing our wallets and so on so that we only trust transactions that have 
confirmations.

The "nSequence=0x means opt-OUT of RBF" convention is only followed by 
fullnodes running standard bitcoind.  Nothing prevents miners from running 
patched bitcoind that ignores this rule, and connecting with similar peers who 
also ignore this rule.

Regards,
ZmnSCPxj


​Sent with ProtonMail Secure Email.​

‐‐‐ Original Message ‐‐‐

On April 11, 2018 5:37 PM, Peter Todd via bitcoin-dev 
 wrote:

> On Wed, Apr 11, 2018 at 05:10:43PM +0900, Karl-Johan Alm wrote:
> 
> > On Wed, Apr 11, 2018 at 4:52 PM, Peter Todd p...@petertodd.org wrote:
> > 
> > > Or via full replace-by-fee, which appears to be used by a significant 
> > > minority
> > > 
> > > of miners:
> > 
> > I was of the impression that final transactions (sequence=0x)
> > 
> > cannot be RBF'd.
> 
> My full-replace-by-fee tree ignores that. It also does preferential peering to
> 
> ensure it's well connected with likewise peers, and thus the whole network.
> 
> 
> ---
> 
> https://petertodd.org 'peter'[:-1]@petertodd.org
> 
> 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] Few questions regarding ListTransaction

[Karl-Johan Alm via bitcoin-dev]

Thanks for clarifying!

On Wed, Apr 11, 2018 at 6:48 PM, ZmnSCPxj  wrote:
> Good morning Karl-Johan Alm,
>
> To clarify:
>
> Nothing prevents a miner from completely ignoring nSequence when putting 
> transactions in blocks.
>
> Unconfirmed transactions are, by definition, not recorded in blocks.  So if 
> there is a transaction 0xFFF nSequence and fee 1000 satoshi, and another 
> conflicting transaction 0xFFF nSequence and fee 1 satoshi, miners 
> can include the latter one even if the first one came to their knowledge 
> first, regardless nSequence.
>
> Thus, in the end "full replace-by-fee", where nSequence is IGNORED for 
> purposes of replace-by-fee, is expected to become the norm, and we should 
> really be designing our wallets and so on so that we only trust transactions 
> that have confirmations.
>
> The "nSequence=0x means opt-OUT of RBF" convention is only followed 
> by fullnodes running standard bitcoind.  Nothing prevents miners from running 
> patched bitcoind that ignores this rule, and connecting with similar peers 
> who also ignore this rule.
>
> Regards,
> ZmnSCPxj
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
>
> On April 11, 2018 5:37 PM, Peter Todd via bitcoin-dev 
>  wrote:
>
>> On Wed, Apr 11, 2018 at 05:10:43PM +0900, Karl-Johan Alm wrote:
>>
>> > On Wed, Apr 11, 2018 at 4:52 PM, Peter Todd p...@petertodd.org wrote:
>> >
>> > > Or via full replace-by-fee, which appears to be used by a significant 
>> > > minority
>> > >
>> > > of miners:
>> >
>> > I was of the impression that final transactions (sequence=0x)
>> >
>> > cannot be RBF'd.
>>
>> My full-replace-by-fee tree ignores that. It also does preferential peering 
>> to
>>
>> ensure it's well connected with likewise peers, and thus the whole network.
>>
>>
>> ---
>>
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>
>> 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] Few questions regarding ListTransaction

[Peter Todd via bitcoin-dev]

On Wed, Apr 11, 2018 at 05:10:43PM +0900, Karl-Johan Alm wrote:
> On Wed, Apr 11, 2018 at 4:52 PM, Peter Todd  wrote:
> > Or via full replace-by-fee, which appears to be used by a significant 
> > minority
> > of miners:
> 
> I was of the impression that final transactions (sequence=0x)
> cannot be RBF'd.

My full-replace-by-fee tree ignores that. It also does preferential peering to
ensure it's well connected with likewise peers, and thus the whole network.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Few questions regarding ListTransaction

[Karl-Johan Alm via bitcoin-dev]

On Wed, Apr 11, 2018 at 4:52 PM, Peter Todd  wrote:
> Or via full replace-by-fee, which appears to be used by a significant minority
> of miners:

I was of the impression that final transactions (sequence=0x)
cannot be RBF'd.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Few questions regarding ListTransaction

[Peter Todd via bitcoin-dev]

On Wed, Apr 11, 2018 at 02:22:42PM +0900, Karl-Johan Alm via bitcoin-dev wrote:
> Clarification on one part below:
> 
> On Wed, Apr 11, 2018 at 2:21 PM, Karl-Johan Alm
>  wrote:
> > On Wed, Apr 11, 2018 at 5:29 AM, Maksim Solovjov via bitcoin-dev
> >  wrote:
> >> 1. What does it mean for a transaction ( with 0 confirmations ) to be
> >> trusted or not?
> >
> > It is trusted if (1) it is final (i.e. it can't be replaced), (2) it
> > is not in a block that was reorged out (negative confirmation count),
> > (3) the 'spend zero conf change' option is set, (4) it is in the
> > mempool, and (5) all inputs are from us.
> 
> "can't be replaced" here means it cannot be replaced through
> conventional means. It is always possible to replace a transaction
> that has not yet been confirmed, e.g. by asking a miner to mine a
> conflicting transaction directly.

Or via full replace-by-fee, which appears to be used by a significant minority
of miners:

https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.16.0

In practice transaction replacement by the sender for any transaction is very
easy.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev