1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
|
Return-Path: <fireduck@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 8016DE24
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 Apr 2018 20:41:21 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr0-f175.google.com (mail-wr0-f175.google.com
[209.85.128.175])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 981EC25A
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 Apr 2018 20:41:20 +0000 (UTC)
Received: by mail-wr0-f175.google.com with SMTP id u11so14065625wri.12
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 Apr 2018 13:41:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=CoHwF3ZCxbhhyL24pq3mhME3EXWSmqI2LA5WHTVdVF0=;
b=OYf+FKIWeTCnhL2yVveBkiW/8mIywA1fJmcmaMTac/5JjQ8CkplXINEIZL6JISZc2t
tg5j0ZEHLA4BM16BaZ1uPA20xdyxSPDwdof3f0/y+v1KDr6NXSf4LXs+MPdjNTWl37ox
T0HR5pcSZnfXQtspyocdVIoGSsQr9S3Pv/2dX7usjs0jAsq6HuTtDP8cNgOyfvHTbxab
DauWTnbgAcVBDG5UuuV7fq5SelOUByIjSIXQjWPeJEq4cumknspXjF5CnkLTHi6DRP2n
98h7bymVSB5jPi+nm4wHDdLArMk8eIR0LNd2LzLQjZnR7MoWYIkCst9tyBefAoWPOeb2
ttZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to;
bh=CoHwF3ZCxbhhyL24pq3mhME3EXWSmqI2LA5WHTVdVF0=;
b=AoKhSJWjSNGRPiHrWHXHiUSTACL25mhioBt/E21E1uA5NT4jpTYKltXjG6z1jnZdq/
H/33AXYfv16deItLy/q/eBiMGvqAzxRDKgB9MlGXtmHCrWIC21m1MRAgJ4NY95z+z5VW
jgiHQ/DbpsyVJvxJssqHg7T9g/XGwvcN0KEpkGuXOPAtDsGq2opEnOf3ctg9/lV5gsjF
Sk9wLGHvZ32Ko0LG6kRE7g0km7vsaiYTOK6OSgduNg9eOE74nURa6SKndD2Sxx7Ir3Q0
ykxGXqx+MtRJSdOqRTpMVR7r7uSO92aNiKi5okulSw1pWQKDQrubtWhyugo0E9vhKkQh
M+vQ==
X-Gm-Message-State: ALQs6tD+NgNAq7YZeZorNi4b1fLZV+SRHc077yn7tEcJFJerAD63eeD+
85DKyzFBzpzyrqHQ4LS56ePY6hDPgsH/6op/Uew=
X-Google-Smtp-Source: AIpwx4+B4Jps5nZP51/X7uIWt7rNeMirbwZT4+o7amSuzQGpn6nnyii6LbFjAYigKr5N7xWO1B62zUN99bfEnp5JGE4=
X-Received: by 10.223.187.75 with SMTP id x11mr1298427wrg.217.1523392879153;
Tue, 10 Apr 2018 13:41:19 -0700 (PDT)
MIME-Version: 1.0
References: <CAO11aqjomkZcr8yeKtT5M8VUROGwz56w11UzR0pDBu333=BEPg@mail.gmail.com>
In-Reply-To: <CAO11aqjomkZcr8yeKtT5M8VUROGwz56w11UzR0pDBu333=BEPg@mail.gmail.com>
From: =?UTF-8?B?Sm9zZXBoIEdsZWFzb24g4pGI?= <fireduck@gmail.com>
Date: Tue, 10 Apr 2018 20:41:07 +0000
Message-ID: <CA+ASnrFMXc66ei=xnyRVwegEo+t3ivQTGFCNkv+KgU2kAPH95Q@mail.gmail.com>
To: Maksim Solovjov <maxim.solovjov@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="089e0820d52c6a59740569848bab"
X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_EXCESS_BASE64,
HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Tue, 10 Apr 2018 20:42:58 +0000
Subject: Re: [bitcoin-dev] Few questions regarding ListTransaction
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Apr 2018 20:41:21 -0000
--089e0820d52c6a59740569848bab
Content-Type: text/plain; charset="UTF-8"
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
>
--089e0820d52c6a59740569848bab
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">2) -1 doesn't mean conflicted, it means the transactio=
n is not only unconfirmed buy depends on another unconfirmed transaction.<d=
iv><br></div><div>1) Depends on what you mean by trusted.=C2=A0 If you are =
giving the user online access to something that costs you next to nothing t=
o revoke if there is a problem later, no problem.=C2=A0 0-conf is great.=C2=
=A0 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.=C2=A0 If you are se=
nding some other non-reversible thing like crypto, then you might want to b=
e careful.=C2=A0 It really depends on the value of your things and your tol=
erance of risk.</div><div><br></div><div>In my opinion, an zero-conf transa=
ction is way way better than a credit card preauth or a check in hand.</div=
><div><br><div><br></div></div></div><br><div class=3D"gmail_quote"><div di=
r=3D"ltr">On Tue, Apr 10, 2018 at 1:34 PM Maksim Solovjov via bitcoin-dev &=
lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lis=
ts.linuxfoundation.org</a>> wrote:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr">Hi,<div><br></div><div>I have few questions regarding L=
istTransaction RPC call and I hope you can help me.</div><div>Documentation=
for the RPC call is here:</div><div><a href=3D"https://bitcoin.org/en/deve=
loper-reference#listtransactions" target=3D"_blank">https://bitcoin.org/en/=
developer-reference#listtransactions</a><br></div><div><br></div><div>1. Wh=
at does it mean for a transaction ( with 0 confirmations ) to be <u>trusted=
</u> or not?</div><div>There is such field in the response of ListTransacti=
on</div><div>As far as I know bitcoin - nothing is trusted unless there are=
some numbers of confirmations.</div><div>How does this value is set to tru=
e or false?</div><div><br></div><div>2. When does <u>confirmations</u> can =
be -1 ( conflicted )?</div><div>What does it mean to have conflicted transa=
ction?</div><div>Is it about Transaction Malleability? Double Spend? or bot=
h?</div><div><br></div><div>3. <u>walletconflicts</u>. What if I add watch-=
only address to my bitcoind process.</div><div>This address will not be a p=
art of my wallet.</div><div>Now, someone will pay me to this address and so=
meone else will make Transaction Malleability ( for the sake of example, le=
ts assume this second one will be confirmed, not the original one ).</div><=
div>Will I get a first transaction in <u>walletconflicts</u> array when Lis=
tTransaction will return me second transaction in the response?</div><div><=
br></div><div>Thank you in advance!</div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--089e0820d52c6a59740569848bab--
|