* [bitcoin-dev] Few questions regarding ListTransaction
@ 2018-04-10 20:29 Maksim Solovjov
2018-04-10 20:41 ` Joseph Gleason ⑈
2018-04-11 5:21 ` Karl-Johan Alm
0 siblings, 2 replies; 10+ messages in thread
From: Maksim Solovjov @ 2018-04-10 20:29 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 1109 bytes --]
Hi,
I have few questions regarding ListTransaction RPC call and I hope you can
help me.
Documentation for the RPC call is here:
https://bitcoin.org/en/developer-reference#listtransactions
1. What does it mean for a transaction ( with 0 confirmations ) to be
*trusted* or not?
There is such field in the response of ListTransaction
As far as I know bitcoin - nothing is trusted unless there are some numbers
of confirmations.
How does this value is set to true or false?
2. When does *confirmations* can be -1 ( conflicted )?
What does it mean to have conflicted transaction?
Is it about Transaction Malleability? Double Spend? or both?
3. *walletconflicts*. What if I add watch-only address to my bitcoind
process.
This address will not be a part of my wallet.
Now, someone will pay me to this address and someone else will make
Transaction Malleability ( for the sake of example, lets assume this second
one will be confirmed, not the original one ).
Will I get a first transaction in *walletconflicts* array when
ListTransaction will return me second transaction in the response?
Thank you in advance!
[-- Attachment #2: Type: text/html, Size: 1449 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Few questions regarding ListTransaction
2018-04-10 20:29 [bitcoin-dev] Few questions regarding ListTransaction Maksim Solovjov
@ 2018-04-10 20:41 ` Joseph Gleason ⑈
2018-04-11 5:21 ` Karl-Johan Alm
1 sibling, 0 replies; 10+ messages in thread
From: Joseph Gleason ⑈ @ 2018-04-10 20:41 UTC (permalink / raw)
To: Maksim Solovjov, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2193 bytes --]
2) -1 doesn't mean conflicted, it means the transaction is not only
unconfirmed buy depends on another unconfirmed transaction.
1) Depends on what you mean by trusted. If you are giving the user online
access to something that costs you next to nothing to revoke if there is a
problem later, no problem. 0-conf is great. If you are pre-pairing
shipments and will be able to pull the box from the ship stream if there is
a problem, also no problem. If you are sending some other non-reversible
thing like crypto, then you might want to be careful. It really depends on
the value of your things and your tolerance of risk.
In my opinion, an zero-conf transaction is way way better than a credit
card preauth or a check in hand.
On Tue, Apr 10, 2018 at 1:34 PM Maksim Solovjov via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> Hi,
>
> I have few questions regarding ListTransaction RPC call and I hope you can
> help me.
> Documentation for the RPC call is here:
> https://bitcoin.org/en/developer-reference#listtransactions
>
> 1. What does it mean for a transaction ( with 0 confirmations ) to be
> *trusted* or not?
> There is such field in the response of ListTransaction
> As far as I know bitcoin - nothing is trusted unless there are some
> numbers of confirmations.
> How does this value is set to true or false?
>
> 2. When does *confirmations* can be -1 ( conflicted )?
> What does it mean to have conflicted transaction?
> Is it about Transaction Malleability? Double Spend? or both?
>
> 3. *walletconflicts*. What if I add watch-only address to my bitcoind
> process.
> This address will not be a part of my wallet.
> Now, someone will pay me to this address and someone else will make
> Transaction Malleability ( for the sake of example, lets assume this second
> one will be confirmed, not the original one ).
> Will I get a first transaction in *walletconflicts* array when
> ListTransaction will return me second transaction in the response?
>
> Thank you in advance!
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 3036 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Few questions regarding ListTransaction
2018-04-10 20:29 [bitcoin-dev] Few questions regarding ListTransaction Maksim Solovjov
2018-04-10 20:41 ` Joseph Gleason ⑈
@ 2018-04-11 5:21 ` Karl-Johan Alm
2018-04-11 5:22 ` Karl-Johan Alm
1 sibling, 1 reply; 10+ messages in thread
From: Karl-Johan Alm @ 2018-04-11 5:21 UTC (permalink / raw)
To: Maksim Solovjov, Bitcoin Protocol Discussion
On Wed, Apr 11, 2018 at 5:29 AM, Maksim Solovjov via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> 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.
> 2. When does confirmations can be -1 ( conflicted )?
> What does it mean to have conflicted transaction?
> Is it about Transaction Malleability? Double Spend? or both?
A transaction is conflicted if a different transaction exists that
spends the same inputs. A transaction gets -N confirmations if it is
mined in a block, and that block is orphaned away, and a different
transaction is mined in the new block so that the transaction becomes
a double spend.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Few questions regarding ListTransaction
2018-04-11 5:21 ` Karl-Johan Alm
@ 2018-04-11 5:22 ` Karl-Johan Alm
2018-04-11 7:52 ` Peter Todd
0 siblings, 1 reply; 10+ messages in thread
From: Karl-Johan Alm @ 2018-04-11 5:22 UTC (permalink / raw)
To: Maksim Solovjov, Bitcoin Protocol Discussion
Clarification on one part below:
On Wed, Apr 11, 2018 at 2:21 PM, Karl-Johan Alm
<karljohan-alm@garage•co.jp> wrote:
> On Wed, Apr 11, 2018 at 5:29 AM, Maksim Solovjov via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Few questions regarding ListTransaction
2018-04-11 5:22 ` Karl-Johan Alm
@ 2018-04-11 7:52 ` Peter Todd
2018-04-11 8:10 ` Karl-Johan Alm
0 siblings, 1 reply; 10+ messages in thread
From: Peter Todd @ 2018-04-11 7:52 UTC (permalink / raw)
To: Karl-Johan Alm, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1252 bytes --]
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
> <karljohan-alm@garage•co.jp> wrote:
> > On Wed, Apr 11, 2018 at 5:29 AM, Maksim Solovjov via bitcoin-dev
> > <bitcoin-dev@lists•linuxfoundation.org> 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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Few questions regarding ListTransaction
2018-04-11 7:52 ` Peter Todd
@ 2018-04-11 8:10 ` Karl-Johan Alm
2018-04-11 9:37 ` Peter Todd
0 siblings, 1 reply; 10+ messages in thread
From: Karl-Johan Alm @ 2018-04-11 8:10 UTC (permalink / raw)
To: Peter Todd; +Cc: Bitcoin Protocol Discussion
On Wed, Apr 11, 2018 at 4:52 PM, Peter Todd <pete@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=0xffffffff)
cannot be RBF'd.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Few questions regarding ListTransaction
2018-04-11 8:10 ` Karl-Johan Alm
@ 2018-04-11 9:37 ` Peter Todd
2018-04-11 9:48 ` ZmnSCPxj
0 siblings, 1 reply; 10+ messages in thread
From: Peter Todd @ 2018-04-11 9:37 UTC (permalink / raw)
To: Karl-Johan Alm; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 553 bytes --]
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 <pete@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=0xffffffff)
> 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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Few questions regarding ListTransaction
2018-04-11 9:37 ` Peter Todd
@ 2018-04-11 9:48 ` ZmnSCPxj
2018-04-11 10:00 ` Karl-Johan Alm
0 siblings, 1 reply; 10+ messages in thread
From: ZmnSCPxj @ 2018-04-11 9:48 UTC (permalink / raw)
To: Peter Todd, Bitcoin Protocol Discussion
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 0xFFFFFFF nSequence and fee 1000 satoshi, and another conflicting transaction 0xFFFFFFF nSequence and fee 100000000 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=0xFFFFFFFF 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 pete@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=0xffffffff)
> >
> > 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Few questions regarding ListTransaction
2018-04-11 9:48 ` ZmnSCPxj
@ 2018-04-11 10:00 ` Karl-Johan Alm
2018-04-11 19:58 ` Maksim Solovjov
0 siblings, 1 reply; 10+ messages in thread
From: Karl-Johan Alm @ 2018-04-11 10:00 UTC (permalink / raw)
To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion
Thanks for clarifying!
On Wed, Apr 11, 2018 at 6:48 PM, ZmnSCPxj <ZmnSCPxj@protonmail•com> 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 0xFFFFFFF nSequence and fee 1000 satoshi, and another conflicting transaction 0xFFFFFFF nSequence and fee 100000000 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=0xFFFFFFFF 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 pete@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=0xffffffff)
>> >
>> > 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
>
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Few questions regarding ListTransaction
2018-04-11 10:00 ` Karl-Johan Alm
@ 2018-04-11 19:58 ` Maksim Solovjov
0 siblings, 0 replies; 10+ messages in thread
From: Maksim Solovjov @ 2018-04-11 19:58 UTC (permalink / raw)
To: Karl-Johan Alm, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2800 bytes --]
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 <ZmnSCPxj@protonmail•com> 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 0xFFFFFFF nSequence and fee 1000 satoshi, and
> another conflicting transaction 0xFFFFFFF nSequence and fee 100000000
> 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=0xFFFFFFFF 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 pete@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=0xffffffff)
> >> >
> >> > 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
>
[-- Attachment #2: Type: text/html, Size: 4232 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2018-04-11 19:58 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-04-10 20:29 [bitcoin-dev] Few questions regarding ListTransaction Maksim Solovjov
2018-04-10 20:41 ` Joseph Gleason ⑈
2018-04-11 5:21 ` Karl-Johan Alm
2018-04-11 5:22 ` Karl-Johan Alm
2018-04-11 7:52 ` Peter Todd
2018-04-11 8:10 ` Karl-Johan Alm
2018-04-11 9:37 ` Peter Todd
2018-04-11 9:48 ` ZmnSCPxj
2018-04-11 10:00 ` Karl-Johan Alm
2018-04-11 19:58 ` Maksim Solovjov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox