s7r [ARCHIVE] on Nostr: 📅 Original date posted:2014-09-26 📝 Original message:-----BEGIN PGP SIGNED ...

📅 Original date posted:2014-09-26
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 9/26/2014 5:16 AM, Matt Whitlock wrote:
> Probably the first double-spend attempt (i.e., the second
> transaction to spend the same output(s) as another tx already in
> the mempool) would still need to be relayed. A simple
> "double-spend alert" wouldn't work because it could be forged. But
> after there have been two attempts to spend the same output, no
> further transactions spending that same output should be relayed,
> in order to prevent flooding the network.
>
This sounds rational - is this already implemented nowadays or *SHOULD
BE* implemented to prevent this attack type in the future?
>
> On Thursday, 25 September 2014, at 7:12 pm, Aaron Voisine wrote:
>> Something like that would be a great help for SPV clients that
>> can't detect double spends on their own. (still limited of
>> course to sybil attack concerns)
>>
>> Aaron Voisine breadwallet.com
>>
>>
>> On Thu, Sep 25, 2014 at 7:07 PM, Matt Whitlock
>> <bip at mattwhitlock.name> wrote:
>>> What's to stop an attacker from broadcasting millions of
>>> spends of the same output(s) and overwhelming nodes with
>>> slower connections? Might it be a better strategy not to relay
>>> the actual transactions (after the first) but rather only
>>> propagate (once) some kind of double-spend alert?
>>>
>>>
>>> On Thursday, 25 September 2014, at 7:02 pm, Aaron Voisine
>>> wrote:
>>>> There was some discussion of having nodes relay
>>>> double-spends in order to alert the network about double
>>>> spend attempts.
>>>>
>>>> A lot more users will be using SPV wallets in the future,
>>>> and one of the techniques SPV clients use to judge how likely
>>>> a transaction is to be confirmed is if it propagates across
>>>> the network. I wonder if and when double-spend relaying is
>>>> introduced, if nodes should also send BIP61 reject messages
>>>> or something along those lines to indicate which
>>>> transactions those nodes believe to be invalid, but are
>>>> relaying anyway.
>>>>
>>>> This would be subject to sybil attacks, as is monitoring
>>>> propagation, however it does still increase the cost of
>>>> performing a 0 confirmation double spend attack on an SPV
>>>> client above just relaying double-spends without indicating
>>>> if a node believes the transaction to be valid.
>>>>
>>>> Aaron Voisine breadwallet.com
>>>
>
> ------------------------------------------------------------------------------
>
>
>
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS
> Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download
> White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with
> EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>
>
>
_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

- --
s7r
PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUJZPVAAoJEIN/pSyBJlsRfgoIAI4x4qITdCDyYx/I1+z4eGz3
u7zDbVGQEPsUlrgEZLf503TNUIKmEgYQvgQDGEdOQk615XlkrTJeqt5oLh9DVJKj
TaXRqKgBp4iNd6BIIs1gKl0CzmH9sJ7U9ojhTS5aV7ZUhinO0WZlgISYaBZ3t9Kw
t//jb8QNLqISOeotiO9A2jb06UVRf9Gh0FUSBYTJ/st0UvLWt286zT+4XOaeVI/c
9I9nkTsd/jdw1Eorfcd5T8iHBORcdn9g+5+UpuXVq7d3KA5FA6oetzBVHgUfTMjF
q9LAe0W9IUVSiRj+wWvADzlxeUwWjsHnJDxdGihBg/g+k6SfPnOAxEC1UjCH+OU=
=kaIX
-----END PGP SIGNATURE-----