Nostr notes by

📅 Original date posted:2015-06-19 📝 Original ...

2023-06-07T15:39:16Z

In reply to nevent1q…5l69
_________________________

📅 Original date posted:2015-06-19
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2015-06-19 15:11, Peter Todd wrote:
> If you ask me to pay you 1BTC at address A and I create tx1 that pays
> 1BTC to A1 and 2BTC of chain to C, what's wrong with me creating tx2
> that still pays 1BTC to A, but now only pays 1.999BTC to C? I'm not
> defrauding you, I'm just reducing the value of my change address to pay
> a higher fee. Similarly if I now need to pay Bob 0.5BTC, I can create
> tx3 paying 1BTC to A, 0.5BTC to B, and 1.498BTC to C.
>
> Yet from the point of view of an external observer they have no idea
> why
> the transaction outputs reduced in size, nor any way of knowing if
> fraud
> did or did not occur.

If there are two transactions which spend the same inputs, and each
transaction has completely different output scripts, then this is prima
facie fraudulent. https://en.wikipedia.org/wiki/Prima_facie

If the two transactions have identical output scripts, and one output is
reduced in value to increase the transaction fee, that has the
appearance of honest dealing. There is a possibility that the payer has
chose to under-pay their payee in order to over-pay the miner, but
that's not what a reasonable observer would assume at first glance.

Adding outputs to a transaction, while keeping all the existing outputs
exactly how they are is another way of increasing the transaction fee of
a transaction and is prima facie non-fraudulent.

Note that child-pays-for-parent has none of this ambiguity.

> What do you think of Bitcoin XT then? It relays double-spends, which
> makes it much easier to get double-spends to miners than before. In
> particular you see a lot of zero-fee transactions being replaced by
> fee-paying transactions, relayed through Bitcoin XT nodes and then
> mined. Is that encouraging fraud?

I haven't closely looked into the features of Bitcoin XT because I'm
hoping that it never becomes relevant. I do want to see a heterogenous
implementation network develop, but Bitcoin XT doesn't really count
since it's a derivative of the Bitcoin Core codebase.

In general, I think every signed Bitcoin transaction sent between
different parties is part of a valid, enforceable contract (using common
law definitions which predate any particular legal jurisdiction).
Handling contracts and money is Serious Business and so the decision of
how software should respond to double spends should not be made
frivolously.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJVhDcpAAoJECpf2nDq2eYj23gP/ja9zqWZBoI/EfTJM0ZDVVY1
7lNwPJrAhO7oKQOKDrqhimA0TPRkoU0rCoYXSUEWn5X8ZIFlz9SQnGwXjIxt7PfG
yZTxF+vJbFCDifNcUlF7DRs07cavEFM9AOutYi8PyVg0LoV5+0VMhhWT4Kc5vnlZ
4Tw91r1lvtI9MCif+KFpida/PnPlhvIfjASEuaK+vYx3ro1ovSUesh558xZmCZ9A
Jfs+EwXBrxDO0zC0fatnaoRMkYQN7i/Dq1PFis7OHcZYBaQwgQTUoF8/wASvr8fQ
dPXJNzhgpYYXeu4IsYH/Of9HkEw+N+/0DEW07asJJ5OIgQmcyoGn+ph8QzrPqG5m
Rgb9BAmpqfCX+KrG6VDxU7xHLebwPhrPoYMIppvf77xhB2mV8c7Xky16Y/1tmxcH
NLOL/WQelNBqCvx2+6c9yDJsJoY12Z0n1tdbIfp3m65xcFzqHPFPtTpsNl0p/gX7
xOMSEUdSVyjvsJjXxWOG3B06+dVRqjS0Pr9ERjjviqx40XVpg4Q0b6y+LL0ZVweE
vs8ECN4y3vB7Qg2swYryVA7kNBh6GwCs7pMCh0DFw1mynGKndCKD+cPh8r3taP1u
8SlrKaD33schk4x70kxbtUzU+C7Yb5187Ct4U5kmsXhz1sypu4ebFPuWbJYG/Sjl
uEW4Vcn+HxlNI/rhxBw4
=odRL
-----END PGP SIGNATURE-----

📅 Original date posted:2015-06-19 📝 Original ...

2023-06-07T15:39:14Z

In reply to nevent1q…rx5y
_________________________

📅 Original date posted:2015-06-19
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2015-06-19 17:40, Jeff Garzik wrote:
> Making multiple incompatible versions of a spend is a -requirement- of
> various refund contract protocols.

Is there not a dedicated field in a transaction (nSequence) for express
purpose of indicating when a protocol like this is in use?

As far as I know, transactions which are using those protocols can be
easily differentiated from those that aren't (which is probably good
from a payment assurance standpoint and bad from a privacy standpoint).

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJVhFW3AAoJECpf2nDq2eYjkegQAINcnzIPbO/bKqNv14TOonb8
9g/pfvMSQyZjUiu4rB6Iwtn+h1hyLkPc3cdSFV4diQSWeG7Q27ZJzH1T1kYdKp4W
DDH8DwD8PtOu+dgRK9eBsy9h72OncA4JTFhnAXMgfLVBY9eRqXk/DWlzwV/WOn/j
3G5xKKOOeHmKJCaKFwdpZghraLouS72AKSdxCNvleRc4zllV+zqWyHHssNDg7sGH
b/62O3DBZXdlzIEzK8/IeaNMY+UXd984/yQ8KCrHCKjc9uiUjNUCCw4JPo4rB/ZA
Itoc8b6pexRs8h40FdXGYAwvN5xQgcaOL7SsN2nNx/DQWYf+1krBO8Iy4kYw2KGl
8JctcHBOI2gLCxTpB2cWeGPwBQbKJhPsmxTxaTNw5fC6ycAnjoJ2bO1Uz0KfwdnI
2jmwxccB9KauC9zNthxGbvdsHOxE8foZ6AnSDI/qbYQK6MqtSnsa7BUn8vc/y4Uf
bVCsxiywVlHttCJqPh5v16rejCcH2el5Rd5PVCkEagxYFfLA3681ZJKD22UV742l
n8ii7RUJXeps6zjRAc35Ccj5qjhB4SP4qYvKmyEoltYbw1EwXbm93UCsFpuxmQ9g
GbQ/jZXsB1cmHBC+c+3X6SaU6eZdy2jDHsICP7sMx2CrZpcZZO058bqRbmdk8JE6
JI17MYG0ofTLfdCfkgEG
=en1q
-----END PGP SIGNATURE-----

📅 Original date posted:2015-06-19 📝 Original ...

2023-06-07T15:39:14Z

In reply to nevent1q…u2uw
_________________________

📅 Original date posted:2015-06-19
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2015-06-19 17:50, Jeff Garzik wrote:
> No. You cannot know which is the 'right' or wrong transaction. One tx
> has
> obvious nSequence adjustments, the other - the refund transaction - may
> not.

I'm still not seeing a case where a node could see conflicting
transactions on the network as part of a micropayment channel, and not
know it was observing the resolution of a channel rather than a likely
retail double spend.

If both transactions have been broadcast, then one of the conflicting
members of the set will have nSequence adjustments.

Maybe a clever griefer could try to make their retail double spend look
like a micropayment channel, but it seems like they'd be missing the
other identifiable markers of that protocol.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJVhFhqAAoJECpf2nDq2eYjWtgP/2ir11TUfxoIIzK9t0groKY3
yMR32HP3caDLKdc5ML41jf0l0cp7a54sFPuRE+Am8rkg9ogcf6fho/hCwLnhhNb4
YYBqJ2pzqCU1uN8jwPYSwSw3AO+F+hPE8gcm7lKD297a1k9xpYayAFjChJowoyNT
Wuq9YDkakQeSjV1aCiRHuXNxqnnbymf9xHEiB0buVnSgnyXrgZNCnefAo8DeXYqi
FTSceakNwdkklddK5ObNNK9ZoLpjHhX6hZwRiXsOoG+WUzXhLQ+BsyIFzsCKxQk1
cXjTvLn+Ub9FasRCK5KXMBkkPa1U5JLs1nTn6eTbPyroTs10WLkXWjIpZHrkf7ZW
9RsxoKIRaJur8gbYd6BMvV5rgkfGdb6j24pVNxFF2t89SLo44H0NvqE6koNzgubG
4DyXZ+UlzxzwRVBNDeF4pdlKZGsz2ycvQPuNHRoaZY2IsieMBN/5HEqGNOmXsvKf
tCg1SInO/FkE4njCxSW0R31s2KXCpgVCuq3qmoIKZobDdx7AC8GnpY1rdxUGpVoy
USJwZ2IOgtNfl/rBtOpkp/BaUCmCYOiUj13/ycDrqWvnM4TmiDdzJNEZNfez5UQp
Uvgvstoo88sewv9hGsuBWX0nC+ze/m43ZRReFhQDsypEaOw6pL2LSG9dD3tzulax
TrbPXPlN55NarQ3nmPIW
=Hj0x
-----END PGP SIGNATURE-----

📅 Original date posted:2015-06-19 📝 Original ...

2023-06-07T15:39:13Z

In reply to nevent1q…vx5r
_________________________

📅 Original date posted:2015-06-19
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2015-06-19 16:36, Matt Whitlock wrote:
> On Friday, 19 June 2015, at 3:53 pm, justusranvier at riseup.net wrote:
>> I'd also like to note that "prima facie" doesn't mean "always", it
>> means
>> that "the default assumption, unless proven otherwise."
>
> Why would you automatically assume fraud by default? Shouldn't the
> null hypothesis be the default? Without any information one way or
> another, you ought to make *no assumption* about the fraudulence or
> non-fraudulence of any given double-spend.

If we have ECDSA proof that an entity intentionally made and publicly
announced incompatible promises regarding the disposition of particular
Bitcoins under their control, then why shouldn't that be assumed to be a
fraud attempt unless shown otherwise?

There are ways of achiving transaction fee adjustment after broadcast
that do not present the appearance of, or opportunity for, fraud. If
those options are available and the user chooses not to use them in
favor of the option that does, that makes bad intentions even more
probable.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJVhEasAAoJECpf2nDq2eYjcwIP/25yoRpNvZkkdFfYiBKaiL/g
XRH8iFAyM5q3/75sA23vD/fzCNGIRRWYyp8PWk+23NF1gdsgVU6gFNNCUmDbjANv
nWTt2Bd926St24jcU+OxMewSGlxpenDSFDNQVtxhNFKst6hoPatwK1Zfa0Eq7/Qw
+r0H2Pse1ulrN4P1n5xnrYMq2w/GF3zinNZbrn2KOZCnsDa8lKlP8y9eNFHBJ//Z
wDrOcfZ1WLhf5/5xlV1NiH0tdxzABilH0ITimm2LCKbj3JcSJayZlyu4n3NypE0E
cVFeYpBaVZW9wuKUv/va5fzcyWDFPAo+OrR2B3siAb8nfY1jONXNhuV3yZ76pzMr
j39lvuSpoTbLobnEWMCJQ5bI/ngbhatT57gqMfF92sO0YjMe/gi/iU6urR9fi5Gz
3Ov6QA78vxzy/YduFjkc/1FV2dNdbGJtq6b0stmz5TtM1uljeGUoj6JZ8kOJ0EXn
857KFAqEd3hG9eYtBdFQcYeV2ShndALBQE0k3cqQvV6XYdHwHuTY15i1nq+u91MZ
VwsR1M69PrDX5Ps6qo1F6QYJA/fA4fyOZ9dwIvh+cgtu4wBptr/NOpL3XH0kE2+G
b2FRGOwdb2KlejIXSL9p4mfJTX9lmk4twbZe2Spjiy4FinOUyzxEobNoUTMcFCU7
Zu2i5yjMlJzrDB8yXz/N
=xtXD
-----END PGP SIGNATURE-----

📅 Original date posted:2015-06-20 📝 Original ...

2023-06-07T15:39:10Z

In reply to nevent1q…x6tt
_________________________

📅 Original date posted:2015-06-20
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2015-06-20 18:20, Jorge Timón wrote:
> On Fri, Jun 19, 2015 at 6:42 PM, Eric Lombrozo <elombrozo at gmail.com>
> wrote:
>> If we want a non-repudiation mechanism in the protocol, we should
>> explicitly define one rather than relying on “prima facie”
>> assumptions. Otherwise, I would recommend not relying on the existence
>> of a signed transaction as proof of intent to pay…
>
> Non-repudiation can be built on top of the payment protocol layer.

Non-repudiation is an intrinsic property of the ECDSA signatures which
Bitcoin uses - it's not a feature that needs to be built.

There's no way to accidentally sign a transaction and accidentally
announce it publicly. There is no form of third-party error that can
result in a payee receiving an erroneous contract.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJVhfkXAAoJECpf2nDq2eYjTwIP/ApsURTKJgAsSYb4/lvoujAE
EhOUBfmb+WkrEceASWGgmXFfQBQW7c99sT46cA1HdCPLZMtYhZYPubtYRouSupfF
vOfeKLsZsUXCadeLuzxP7av3PJhmvB1CO1Rv8CLBQptKUFkzyM3CypBviNTy33X6
KL2zyAMERpCVOejg7MSP3IUXIjgG1ayEm+mzwqi4j2Ms0h+oT6I/krAKV0J9SwJC
PtLq/JRRriVtb2FE+biEqYRYfeOcZDYNbr+/y0HPtqqMxg6azNwx1z2aG5A+ziCd
EvVqVJXU3TAINQdIvVS4ACF1J+ttMJ99r8VW0yN7o3fEckuRr3pyymx4I+XExSX5
ujflqadRGUS8ZenUPTPUbLfhARnmBwLM94L+xiQvIwiinxxtOKn3WW1oDv9FNp0l
99fkv9mbV5RnYlkMfWMn2AcwcBv7TSgpFGsZY4wBn/mgFh1PotGc2tA5kU79cz8R
+F/k49+GwfgTPML7UhIGtjQjPreeqDyHNtv9XHtyp8LF5vO1na4oHSO6SeU4rIXH
4oIjw+Q6X/2L/fp8QNLB+onmKWobcl1Ec+0H+ZfQBujtew5BHFwcPwFmlC4tofiJ
7r8QjoPsRhJmaxm+MJOK/BIzhZErkMz26AQ/tfY4jtJCuLbEDdMLtC9hYVuiDHIb
HBxxif83dALjX1Sgid66
=o9dG
-----END PGP SIGNATURE-----

📅 Original date posted:2015-06-20 📝 Original ...

2023-06-07T15:39:10Z

In reply to nevent1q…6862
_________________________

📅 Original date posted:2015-06-20
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2015-06-20 19:19, Eric Lombrozo wrote:
>> On Jun 20, 2015, at 4:37 PM, justusranvier at riseup.net wrote:
>>
>> Signed PGP part
>> On 2015-06-20 18:20, Jorge Timón wrote:
>> > On Fri, Jun 19, 2015 at 6:42 PM, Eric Lombrozo <elombrozo at gmail.com>
>> > wrote:
>> >> If we want a non-repudiation mechanism in the protocol, we should
>> >> explicitly define one rather than relying on “prima facie”
>> >> assumptions. Otherwise, I would recommend not relying on the existence
>> >> of a signed transaction as proof of intent to pay…
>> >
>> > Non-repudiation can be built on top of the payment protocol layer.
>>
>>
>> Non-repudiation is an intrinsic property of the ECDSA signatures which
>> Bitcoin uses - it's not a feature that needs to be built.
>>
>> There's no way to accidentally sign a transaction and accidentally
>> announce it publicly. There is no form of third-party error that can
>> result in a payee receiving an erroneous contract.
>>
>>
>
> Justus,
>
> We don’t even have a concept of identity in the Bitcoin protocol, let
> alone non-repudiation. What good is non-repudiation if there’s no way
> to even associate a signature with a legal entity?
>
> Sure, we could use the ECDSA signatures in transactions as part of a
> non-repudiation scheme - but the recipient would have to also have a
> means to establish the identity of the sender and associate it with
> the the transaction.
>
>
> Furthermore, in light of the fact that there *are* fully legitimate
> use cases for sending conflicting transactions…and the fact that
> determination of intent isn’t always entirely clear…we should refrain
> from attaching any further significance transaction signatures other
> than that “the sender was willing to have it included in the
> blockchain if a miner were to have seen it and accepted it…but perhaps
> the sender would have changed their mind before it actually did get
> accepted.”

Bitcoin has no concept of identity, but in any type of commercial
transaction the parties involved must know some minimal amount of
identity information in order to transact at all.

Except for some identifiable special cases, I think a payee is perfectly
justified in treating a double spend of a payment sent to them as part
of a commercial transaction as a fraud attempt and employing whatever
non-Bitcoin recourse mechanisms, if any, they have access to.

- From the perspective of the network, the obviously correct action for
any node or miner is to relay the first version of any transaction they
see. The primary purpose of mining is to resolve this
otherwise-unresolvable problem of determining which transaction among a
set of conflicting transactions happened first.

If a node or miner wants to deviate from the obviously correct
behaviour, and if they want to avoid harming the value of the network,
they should be particularly careful to make sure their deviation from
"first seen" doesn't introduce harmful unintended side effects, like
making fraud easier.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJVhgTgAAoJECpf2nDq2eYjkksQAJyRVhT2vNQUqlOfH9Z/9EeT
LkUm8eg3f1i3xhJVxtLGVJkRmMYmuNtH0lIsH/B3iED732oZSzhwM1F5ky948Mw7
FFG65iUTrXVup9eKZuD7T3/FaQHfC5YME36F4UvEtSUcRDUKmongRGuuw7sNv617
APl3MDwZ8tVWaDb7yZ251is6Fx1l3b6tR4tHUzyIWPyIOuXOsyUaoS1cYJ00YcI5
WIzIXIlRDNpvpIXv4NFtr0BH6BmTCCZOJH3X9Hmtxqrg/dlnfnmc1pZgAyqRXj1d
5of7dYwb+bhHpU9TvcDYprN55Kmida2gTZewfr33rTXcVyjhs5N3bmIRIRrPltMA
fFqlKJ7Fo4ldyJ4OEK6upuFHwmQRNL7qr/ODmYg83rJj3BdTzXsJ1l3BRAUBS+cm
gc8Q3urxmVyspht+U64GO+ieLA9xb9izFMa+GL8nag0VuHc5J7XDjfzXBT8VK5be
646AZ0tFULNLOBWEJuBRbCRUs90YK2ePpGnAwiZ7HuwHMAC333FYiBuRxgwgn+xv
hHMlQWTtrl0zJrxD+pcb5axC7zQdVHVeyNJDi4RF1Wau2NX/itHcUqRr75N8/Si+
GPF8JSnvLlplEsEMBAtbKvg4dn1AOEuJpXtDYrWrzZDs+/wwz5PfQ2oCZ3YRHNx2
po6di9uOSlLq0BJJfSrM
=HbNG
-----END PGP SIGNATURE-----

📅 Original date posted:2015-06-19 📝 Original ...

2023-06-07T15:39:09Z

In reply to nevent1q…j2sd
_________________________

📅 Original date posted:2015-06-19
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2015-06-19 16:42, Eric Lombrozo wrote:
> If we want a non-repudiation mechanism in the protocol, we should
> explicitly define one rather than relying on “prima facie”
> assumptions. Otherwise, I would recommend not relying on the existence
> of a signed transaction as proof of intent to pay…

Again, I'm not talking about any changes to the protocol. The mining
mechanism in the Bitcoin protocol is the fallback method of resolving
fraud that isn't prevented or resolved via other mechanisms.

There are plenty of other ways economic actors resolve their
disagreements other than blockchain adjudication. Sometimes when both
parties are identified and reside in the same legal jurisdiction,
contract violations and fraud can be adjudicated in courts. In some
situations, the parties involved may have access to private dispute
resolution techniques.

Sometimes the stakeholders in the network act to preserve the long term
value of their investments, even if it means passing short-term profits.
The more of those stakeholders there are in Bitcoin, the more effective
it is to make the case for choices that are long-term beneficial.

The degree to which anyone should rely on a signed transaction as
assurance of future payment is not a question with a universal answer.
It depends on the particular details of the situation, and the parties
involved, and their own risk tolerances and time preferences. There's no
right answer for everyone, which is why "let's break zeroconf because
*I* don't think it's safe enough" is a kind of vandalism.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJVhEkhAAoJECpf2nDq2eYj8qAP/0qYP7FJDjke1qNARGkySjC5
8fSuefu8bus/O2fNYsvPf0OcHeqepLUtQ/hgTml5AHaF1Fa9iZopVr8nZv0NFMuF
sv9RfkBKvnnrLWre3e/kQIdKzdMXompEsDwGfIeM3qvVV9AD3mKrz/YNmjs60+hU
rEdLCX8xw3ZvF3CGOzE1KnOMbADEd7i3E/Pm1n7pLVdRAg2CIU+w6mjErgucSdvB
kQ9SNAVQngjhMJyVbxsQh/+/xgecdqeZ07aaGsLhiw6zML2Tz8KMhrjJ9xw9+7h0
Gze+JdqxpgH4QrvD8KMDnlZjM+cWDUGyoVfsRvrVvPdW6kejU1r1B5Pf6dJg9TwZ
kK48RJFdd2rpAkz/kAbvQtoNMxSxhm2gKKFLEMi7g8MZUiGa/Rxj0tWL7OL9SA1U
VfpUzgAovoat9lBQM92T5vcS6kfhiNgAmF24ULGGYIhts77Ae6h8Fl3TECtnR0dM
1U1yio4Im1TfUDfjqNSK+ZjVpzkQli0R057y6XzI9HWkSYo94WyjNVoUlUozuAam
/2+tUMTrMYPeApRv+1nv13InYO8RZiFqs0E4w4TmB5V4Xt6uGUz4Olioyuo0NqMO
lBZwa1ZWKw4fLgHHDu9FhTEOXsOcX5W0gEgcoqMlzTzyoapekk9Esd0pAFLYxYMY
YQyAWtWUA4JBbgLxlB8Y
=x8eh
-----END PGP SIGNATURE-----

📅 Original date posted:2015-06-19 📝 Original ...

2023-06-07T15:39:07Z

In reply to nevent1q…pha2
_________________________

📅 Original date posted:2015-06-19
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2015-06-19 15:37, Eric Lombrozo wrote:
> OK, a few things here:
>
> The Bitcoin network was designed (or should be designed) with the
> requirement that it can withstand deliberate double-spend attacks that
> can come from anywhere at any time…and relaxing this assumption
> without adequately assessing the risk (i.e. I’ve never been hacked
> before so I can assume it’s safe) is extremely dangerous at best and
> just horrid security practice at worst. Your users might not thank you
> for not getting hacked - but they surely will not like it when you DO
> get hacked…and lack a proper recovery plan.
>
> Furthermore, the protocol itself makes no assumptions regarding the
> intentions behind someone signing two conflicting transactions. There
> are many potential use cases where doing so could make a lot of sense.
> Had the protocol been designed along the lines of, say,
> tendermint…where signing multiple conflicting blocks results in loss
> of one’s funds…then the protocol itself disincentivizes the behavior
> without requiring any sort of altruistic, moralistic assumptions. That
> would also mean we’d need a different mechanism for the use cases that
> things like RBF address.
>
> Thirdly, taken to the extreme, the viewpoint of “signing a conflicting
> transaction is fraud and vandalism” means that if for whatever reason
> you attempt to propagate a transaction and nobody mines it for a very
> long time, you’re not entitled to immediately reclaim those funds…they
> must remain in limbo forever.

I'm not talking about changing the protocol - I'm talking about the
business relationships between users of Bitcoin.

I would expect a payment processor to inform the merchants of relevant
double spends that it observes on the network, even if the payment is
actually successful, so that the merchant can decide for themselves
whether or not to pursue it out of band.

Mining is a kind of technical fallback that allows the network to
resolve human misbehavior without human intervention. If nobody ever
attempted to make a fraudulent payment, we wouldn't need mining at all
because the signed transaction itself is proof of intention to pay. That
it exists doesn't suddenly make fraud less fraudulent and mean that
users who are in a position to pursue out of band recourse shouldn't do
so.

I agree that there are valid reasons for replacing transactions in the
mempool, I just think they should be implemented in a way that doesn't
facilitate fraud.

I'd also like to note that "prima facie" doesn't mean "always", it means
that "the default assumption, unless proven otherwise."

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJVhDqcAAoJECpf2nDq2eYjX/UP/RlVIGqzwvdKftFW8kRW1+Dk
3befE2vEIEWFAShNt0pk7/Isqk7prRWQDKP+VNZSJfaoyE3akOe7s3OPWuevVRqM
Y1N658hYnG6NPebkyp5zUQkjT3mXVxOo9Fw9k7JyHgkWaDcwx330z2n6yztleodq
7hlKdW6sZrgqHw+DoF0Zal3QPN0WYm0XAno3uy71RXOs5cAoUxViuVzWHY0oReTQ
uggTggT1A5acmyOM7v65h9Cb2AKcLvHKfSEIwVQbHxYMOT+3GIJOXPKAluh8MjB3
oWg8ERy5dEEHu5kF/MLPQMg5yVQACuQmO2dlmtRoOs3mUQQj+q7dEil/dZMIp0f+
unDKIwLhXMa0sZ+63123UOgaKGZkF7afed3ueniJWQM80VS0WoZvZYhQadT/sCED
Ntfxifi1ZqCiKFeshyN9z7jDC8QEJ3N176Kr/wX76h/vvnPYicMEcfRgSE8EGd10
+oRQQpYzb69WPSFRhhrR3yG9Dev1JfzNPEaIKKYerDk9Vo3OnQ3VaaqBNZwBDo46
4r3O5orFES/ZxMdzWE1cWp99n4T4L6KxdZXmfQSYHehUJBnt62vKuEk9X/Li2ZWo
i3dr3yxx8xhKGGjsSjG03arz70bkXE7SvrICPOs9OEAdGlJI2liLrSWzYU9BbTle
eWvElyVQJsJHgAU8ygvn
=77NP
-----END PGP SIGNATURE-----

📅 Original date posted:2015-06-19 📝 Original ...

2023-06-07T15:39:06Z

In reply to nevent1q…sg4z
_________________________

📅 Original date posted:2015-06-19
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2015-06-19 10:39, Peter Todd wrote:

Yesterday F2Pool, currently the largest pool with 21% of the hashing
power, enabled full replace-by-fee (RBF) support after discussions
with
me. This means that transactions that F2Pool has will be replaced if
a
conflicting transaction pays a higher fee. There are no requirements
for
the replacement transaction to pay addresses that were paid by the
previous transaction.

Intentional fraud is a bad thing to add to a financial protocol.

A user who creates conflicting transactions, one that pays someone else
and another which does not pay them, and broadcasts both of them, has
just self-incriminated themselves by producing prima facie evidence of
fraud.

It may be the case that since Bitcoin spans multiple legal jurisdictions
and can be use anonymously that the victims of such fraud can not rely
on legal recourse, and it may also be the case that proof of work is how
Bitcoin deals with the aforementioned factors, but regardless
un-prosecutable fraud is still fraud and anyone who encourages it should
be recognied as a bad actors.

Committing vandalism and encouraging fraud to prove a point may be
something the network can't stop on a technical level, but there's no
reason not to call it out for what it is.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJVhCsXAAoJECpf2nDq2eYjA08P/ApDFcIGws55TsgDFxPhDpN+
Iq9a06mPbXVjUfRxP5ZwmJuiM+XzHQ4QL3C2BH0OETatIV+bh7GP2mGHPcUAISYt
1j4TKhurnC+mqN+YAsiI5hQsws8DvPYXBTYYn0savaJTbq6/Q77+xvfRgNxofcPW
EHpnl/5wcmYGgp3mVyStGJ+qIP17yywzCLnSA3WEPaZG/9/FPrIq3Ptw2+RHod79
nzDiFBiKLK8E5NPbdbXS+gkjkkBA/QeCzZObpMOeWMriu/PIifVi8KssLSznnEwx
r7hiv6ISW47BTzkRbjxmXmGep3wfl8MjH7BZq3g0uyiApMdmjohIJ2lyuvOXdh7s
47+4r2xA8gG+z0aQTmCx5TS75T0Hnj3I78ZtCVr31Ip2OLbNI1mQ2gPR2zaoZkUZ
atp2XCssHDlY2s30k5hAnIHxuN6CkyGkZCECSuv46Z3ok6ll/nIP80qB7BBzVlP1
xfSOPZh57J31U8PxZBZcwgdRg+HBiExvg484grE+h18izxcrjNfPRSWP4+7nEZtK
LN7JL7YcmhVfhqKTSd6+C4bD2LsKsrcMiUhH1xHkD/hzAxc7egL6lgYTHJjU+yPu
BTIh0VHJxBgroHB45Vq6loa4B3l4ZCl4Ykw8Opm7NJIfueJ0l0ySyJXi6ix4bjVf
ZRF0Ot9RP0M0fHEwOpT6
=s0w/
-----END PGP SIGNATURE-----

📅 Original date posted:2015-06-18 📝 Original ...

2023-06-07T15:38:32Z

In reply to nevent1q…dyak
_________________________

📅 Original date posted:2015-06-18
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2015-06-18 16:28, Jeff Garzik wrote:
> This is an engineering list. The quote precisely describes how the
> bitcoin
> consensus system functions.
>
> Users' choice is largely binary: Follow the rules, or bitcoin software
> ignores you.

Software engineers should understand that they have a binary choice:
produce the software that your customers want, or the world will ignore
your software.

There is *no inherent value* to Bitcoin's software rules. The only value
that is exists is that produced by the individuals who voluntarily
choose to run the software.

Failing to account for all design requirements is bad engineering.
Nobody cares about the design features of a bridge to nowhere.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJVgvoDAAoJECpf2nDq2eYj0h4P/0YaTsS963qpb63zvB6WlIPS
2lhCJ9FtAd3II5Et+5c/cisfJ9YI2OnM0y8nQpyB9NEOeueN1L1sLFcayE5aHASd
EgF7F81AhQD2iSIVwQNs2qAzrZNC2/Nx+nBzBDcrgZ6gRiPpQdsNLy2p0OuZdOgX
yG4xl6tKADB2kNi6tVPtZqUC300uQHvggtm+pexYilT0ojEbeVHCoDV40MNDZC2h
1kcdTnGU2SHJJqeZN2vChJCOMfhmK4JwKgoz7JRXe/GHkUUJKriE6Kb7SVczii9e
9qfcosbnR3gjATMoHFYuJX/nsUx52Q1LM9eQgvE8Ml+6Mim5bj2KCJFh7YISxSq9
FhDujfZFCRRQLPJCSkEUePxU/LS7lmoTZXYl3Zz1j9zbq4ncpRHpIFy9QX6iIqK6
Dursnge9ELQwB+H6HoosWRzxOZyo+oiGj17OngJvZYcvzrc2wjHbpZfVqSkmZepU
SfJZ64O7yjjXjITwhOc4XF2drzvhsjTsHH5BIwdbCn82SoCkJIwXraj7sxIundli
LUJBPiAE0csdmsvW/2kkxLsd9JwTw9lJ9Pf8fiqH3itgrkPkO5mf10DPPnay1SNk
Wnm1bAJ05WnKXSo0m0SzaFgZkdfFuhWR4fieSzhLpa+s/HHj18NZvJCmCBR6ic9G
0A+51wwSZnAdMIw7lwIb
=r4Co
-----END PGP SIGNATURE-----

📅 Original date posted:2015-06-18 📝 Original ...

2023-06-07T15:38:31Z

In reply to nevent1q…n4sx
_________________________

📅 Original date posted:2015-06-18
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2015-06-18 14:53, Jeff Garzik wrote:
> Consensus changes - worded another way - change Bitcoin's Constitution
> -
> The Rules that everyone in the system is -forced- to follow, or be
> ignored
> by the system.

Force is not a helpful or accurate way to describe the situation.

The purpose of Bitcoin to let people trade with each other, and trade
requires mutual agreement.

If some people choose not to trade under certain terms, they aren't
"forcing" anybody to do anything. They are simply refraining from
proposed interactions. Not granting them the right to do this would
actually be forcing them to engage in interactions against their will.

It's an unavoidable reality that Bitcoin's usefulness is related to the
size (really: economic output) of the group of people who can be
convinced that it's in their best interest to agree on a common trade
protocol.

Conversations that feature untrue claims about someone forcing someone
else to do something is the opposite of a viable strategy for growing
the size of that group.

Arguments about who violated what Bitcoin Core internal governance
procedures are not interesting to most Bitcoin users, who generally
don't know or care who has commit access to the repository.

Getting angry at Gavin and Mike for providing Bitcoin users with an
alternative which they can freely choose or reject is not helpful in
persuading users to stay with Bitcoin Core. Making the case why the
changes in Bitcoin XT are not beneficial to Bitcoin users could be.

For better or for worse, Bitcoin coin users are going to run the
software they perceive to be in their best interests. Nobody can stop
them from making that choice and any effort directed at that end is
wasted.

It's more productive to expend effort making sure the current and future
Bitcoin users are as informed as possible about the long term and short
term consequences of their choices.

Circling back to the original quote:

On 2015-06-18 14:53, Jeff Garzik wrote:
> Consensus changes - worded another way - change Bitcoin's Constitution
> -
> The Rules that everyone in the system is -forced- to follow, or be
> ignored
> by the system.

Bitcoin does not and can not function as a set of rules imposed by some
people onto other people. Bitcoin is a negotiation about the best way
for money to function in the future. The only way we get people to use
Bitcoin is to convince them that the benefits they gain from agreeing to
its protocol outweigh the downsides they encounter.

I'm confident that this case can be made successfully but a prerequisite
to a successful negotiation is recognizing that it is, in fact, a
negotiation, and that the other parties have full agency and the right
to walk away if mutual agreement is not reached.

My suggestion is to spend less time talking about procedural violations
and more time convincing Bitcoin users that Bitcoin Core is the best
client for them to use, especially if the process of convincing them
involves making improvements which the users are asking for (or making a
very compelling case about why the users should reconsider).

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJVguyLAAoJECpf2nDq2eYjTPgP/A16QGWSWkh50OhSjHx7hdY5
v0ZqNvfKSm6a94o22yTQF8VZm7NEJJcNY0Vvu1ro95v27Bm37VodGGOXh4ao9gYQ
ETdzX35OLWUua1e9kfEwgo2Uu2l9AdALOLK5IHyLZdtxJQwUhcdeIhaSMzlZqgEk
n+gbAZXV7JdnK+oejh5s8zgfOY3MqhZC3TQBVWHWx0K0CE75rm0j4ZShYL2eKOua
CmWkcEkfeugrnQQv/BB+oe1TAJoHY4bZAr+amYLZMiC8wRcGGeVBOOFykLNd4rSV
DE+iiGHmgi/wrZjy/xT5kflX55GE8NNVjM2MMNOyD+gWbBn5INahya+DkDWupeQB
iy71NQQVnB/5U5Yhm/oVUax+Cjj/7001cf1q2rXPcjE+4ntw5ad9oCuRW3kSUpzq
C0LqEN2lbagrmk/xHSv/GQl+iWulD1mXJl63y3LdXYWno67eVYqzvRK0UB7ZSVww
3P7p8h2yuvtPtAUDyoOPn7Ghyd1U1lJWGsyffRzd2hWhEYs44cfAv6S2QWIBWbm5
j8C2ao7m6j2mirRZem+bGrN8idR/fOUIjnwqQmNIObsviMrvgXlHvORjsBcdHoKO
9Ir8CvqGWftIG5lLCJvjsnP8E3MRToo6pOsD/Ii9223Pn6DxsMvXF+IkZzUJfWDR
W+t/BYV6XtsAUKI+dAly
=3KeB
-----END PGP SIGNATURE-----

📅 Original date posted:2015-06-16 📝 Original message:On ...

2023-06-07T15:38:07Z

In reply to nevent1q…uj9u
_________________________

📅 Original date posted:2015-06-16
📝 Original message:On 2015-06-16 03:49, Kevin Greene wrote:
> Hah, fair enough, there is no such thing as the "right" way to do
> anything. But I still think punishing users who use SPV wallets is a
> less-than-ideal way to incentive people to run full nodes. Right now
> SPV is
> the best way that exists for mobile phones to participate in the
> network in
> a decentralized way. This proposal makes the user experience for mobile
> wallets a little more confusing and annoying.

Suppose a billion mobile phones wanted to run SPV wallets tomorrow. Who
would provide the nodes they would need connect to? The decentralization
fairy?

There's absolutely no reason that paying for connectivity would be any
more confusing or annoying than transaction fees are.

If some full nodes in the network started offering paid connection
slots, that would just mean that users who checked the "pay subscription
fee" box in their wallet configuration would have an easier time
connecting than the users who did't, just like how your transaction
might eventually get mined without a fee but paying one makes it faster
and more probable.

📅 Original date posted:2015-06-16 📝 Original message:On ...

2023-06-07T15:38:07Z

In reply to nevent1q…n678
_________________________

📅 Original date posted:2015-06-16
📝 Original message:On 2015-06-16 07:55, Aaron Voisine wrote:
>> Suppose a billion mobile phones wanted to run SPV wallets tomorrow.
>> Who
>> would provide the nodes they would need connect to?
>
> The SPV wallet author would if they wanted their wallet to function.

How will the SPV wallet users pay for this service? With their money, or
with their privacy?