From: "Joseph Gleason ⑈" <fireduck@gmail.com>
To: Maksim Solovjov <maxim.solovjov@gmail.com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Few questions regarding ListTransaction
Date: Tue, 10 Apr 2018 20:41:07 +0000 [thread overview]
Message-ID: <CA+ASnrFMXc66ei=xnyRVwegEo+t3ivQTGFCNkv+KgU2kAPH95Q@mail.gmail.com> (raw)
In-Reply-To: <CAO11aqjomkZcr8yeKtT5M8VUROGwz56w11UzR0pDBu333=BEPg@mail.gmail.com>
[-- 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 --]
next prev parent reply other threads:[~2018-04-10 20:41 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-10 20:29 [bitcoin-dev] Few questions regarding ListTransaction Maksim Solovjov
2018-04-10 20:41 ` Joseph Gleason ⑈ [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CA+ASnrFMXc66ei=xnyRVwegEo+t3ivQTGFCNkv+KgU2kAPH95Q@mail.gmail.com' \
--to=fireduck@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=maxim.solovjov@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox