Justus Ranvier [ARCHIVE] on Nostr: š Original date posted:2015-02-12 š Original message:-----BEGIN PGP SIGNED ...
š
Original date posted:2015-02-12
š Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 02/12/2015 05:24 PM, Oleg Andreev wrote:
>
>> I think that is a misdirection on your part. The point of
>> replace-by-fee is to make 0-confirms reliably unreliable.
>> Currently people can "get away" with 0-confirms but it's only
>> because most people arent actively double spending, and when they
>> do it is for higher value targets. Double spend attacks are
>> happening a lot more frequently than is being admitted here,
>> according to Peter from work with various clients.
>>
>> Like single address reuse, people have gotten used to something
>> which is bad. Generally accepting 0-conf is also a bad idea(tm)
>> and instant confirmation solutions should be sought elsewhere.
>> There are already interesting solutions and concepts:
>> greenaddress for example, and CHECKLOCKTIMEVERIFY micropayment
>> channels for example. Rather than supporting and promoting risky
>> 0-confirms, we need to spend time on better alternative solutions
>> that will work for everyone and not during the honeymoon phase
>> where attackers are fewer.
>
> Here's value-free assessment of the issue here:
>
> 1. Zero-conf txs are unsafe. 2. We'd all want to have a safer
> instant payments solution if possible. 3. As a social artifact,
> today zeroconf txs happen to work for some people in some
> situations. 4. Replace-by-fee will break #3 and probably hasten
> development of #2.
>
> The discussion boils down to whether we should make #2 happen
> sooner by breaking remnants of #3 sooner.
>
> I personally would rather not break anything, but work as fast as
> possible on #2 so no matter when and how #3 becomes utterly broken,
> we have a better solution. This implies that I also don't want to
> waste time debating with Peter Todd and others. I want to be ready
> with a working tool when zeroconf completely fails (with that patch
> or for some other reasons).
>
> TL;DR: those who are against the patch are better off building a
> decentralized clearing network rather than wasting time on debates.
> When we have such network, we might all want this patch to be used
> for all the reasons Peter has already outlined.
You've left out of the discussion that many (or all) proposed
solutions for 2 either reduce privacy, or security, or both.
That fact should not be ignored or swept under the rug.
There's also no mention of the degree to which child-pays-for-parent
achieves the stated aims of the original proposal (clearing mempool of
stuck transactions, increasing payee assurance of conformation)
without introducing incentives to double spend or forcing people into
privacy/security sacrifices.
- --
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCAAGBQJU3OzkAAoJECpf2nDq2eYjDM8P/1a4bNa5s0ryMZHBxyhGcVk5
6hTSPpUF2/Y81JaC/EqzH8MMKqnPVcLxoikKoO5tIUxeo5bwC5OO8YyGk4NrpeCM
HTmROR+4XFOULi1dsUs5LP5oBQ+sPu1uNOZKn2fPCgtkO0xj8/w3mCdlVlf7g+v4
bYt6rSmSCzyCY0qFQVYvyBoYeSVt6icdz45D54BvyNsEtlT+HvbNdG/SznT7QsLF
2rOZezp5zbIyhbhaV5KtCKwYzATFYr0nWFHVnBkYWcOY3mJdPg6zODUO5ocbGs45
RHEB8KMsKtrD+gnCwCoSb+J6TNlA8y//ilKemPb+gRSVVM1JJpHBwv7fc8jUu2Ap
V9YNKOVOrmoGb5X2sCctAZ6474p8HCUgZh50OluQph01tGtq3uC1djJUvnVCP232
FQD47AU2LhU3wPjWSGEDIGtpeAk91+6huRCzv600xnIISd5KpryKpD6qWC3M4MGs
G4omAZhHjW5/E8CO/CH21nbPA2P1wozrGE5N8UTc2kwias/4Vn+v3IedjnSiS+IF
n37MzlyCVs9qXyT7WylT4UAnc9exxHwGXKrvcCUaIAw7FOFEHjiHYLjZFIrVWmpM
7qxjMD/yM3kDmd/+YxCbITAERsHh04k4PITLVbnOyXY+axi+Xuow9v5HvwqERvt8
XjbkwrkFIuKfUJyfIuR+
=ony0
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 14416 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/d4df7cc6/attachment.bin>;
š Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 02/12/2015 05:24 PM, Oleg Andreev wrote:
>
>> I think that is a misdirection on your part. The point of
>> replace-by-fee is to make 0-confirms reliably unreliable.
>> Currently people can "get away" with 0-confirms but it's only
>> because most people arent actively double spending, and when they
>> do it is for higher value targets. Double spend attacks are
>> happening a lot more frequently than is being admitted here,
>> according to Peter from work with various clients.
>>
>> Like single address reuse, people have gotten used to something
>> which is bad. Generally accepting 0-conf is also a bad idea(tm)
>> and instant confirmation solutions should be sought elsewhere.
>> There are already interesting solutions and concepts:
>> greenaddress for example, and CHECKLOCKTIMEVERIFY micropayment
>> channels for example. Rather than supporting and promoting risky
>> 0-confirms, we need to spend time on better alternative solutions
>> that will work for everyone and not during the honeymoon phase
>> where attackers are fewer.
>
> Here's value-free assessment of the issue here:
>
> 1. Zero-conf txs are unsafe. 2. We'd all want to have a safer
> instant payments solution if possible. 3. As a social artifact,
> today zeroconf txs happen to work for some people in some
> situations. 4. Replace-by-fee will break #3 and probably hasten
> development of #2.
>
> The discussion boils down to whether we should make #2 happen
> sooner by breaking remnants of #3 sooner.
>
> I personally would rather not break anything, but work as fast as
> possible on #2 so no matter when and how #3 becomes utterly broken,
> we have a better solution. This implies that I also don't want to
> waste time debating with Peter Todd and others. I want to be ready
> with a working tool when zeroconf completely fails (with that patch
> or for some other reasons).
>
> TL;DR: those who are against the patch are better off building a
> decentralized clearing network rather than wasting time on debates.
> When we have such network, we might all want this patch to be used
> for all the reasons Peter has already outlined.
You've left out of the discussion that many (or all) proposed
solutions for 2 either reduce privacy, or security, or both.
That fact should not be ignored or swept under the rug.
There's also no mention of the degree to which child-pays-for-parent
achieves the stated aims of the original proposal (clearing mempool of
stuck transactions, increasing payee assurance of conformation)
without introducing incentives to double spend or forcing people into
privacy/security sacrifices.
- --
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCAAGBQJU3OzkAAoJECpf2nDq2eYjDM8P/1a4bNa5s0ryMZHBxyhGcVk5
6hTSPpUF2/Y81JaC/EqzH8MMKqnPVcLxoikKoO5tIUxeo5bwC5OO8YyGk4NrpeCM
HTmROR+4XFOULi1dsUs5LP5oBQ+sPu1uNOZKn2fPCgtkO0xj8/w3mCdlVlf7g+v4
bYt6rSmSCzyCY0qFQVYvyBoYeSVt6icdz45D54BvyNsEtlT+HvbNdG/SznT7QsLF
2rOZezp5zbIyhbhaV5KtCKwYzATFYr0nWFHVnBkYWcOY3mJdPg6zODUO5ocbGs45
RHEB8KMsKtrD+gnCwCoSb+J6TNlA8y//ilKemPb+gRSVVM1JJpHBwv7fc8jUu2Ap
V9YNKOVOrmoGb5X2sCctAZ6474p8HCUgZh50OluQph01tGtq3uC1djJUvnVCP232
FQD47AU2LhU3wPjWSGEDIGtpeAk91+6huRCzv600xnIISd5KpryKpD6qWC3M4MGs
G4omAZhHjW5/E8CO/CH21nbPA2P1wozrGE5N8UTc2kwias/4Vn+v3IedjnSiS+IF
n37MzlyCVs9qXyT7WylT4UAnc9exxHwGXKrvcCUaIAw7FOFEHjiHYLjZFIrVWmpM
7qxjMD/yM3kDmd/+YxCbITAERsHh04k4PITLVbnOyXY+axi+Xuow9v5HvwqERvt8
XjbkwrkFIuKfUJyfIuR+
=ony0
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 14416 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/d4df7cc6/attachment.bin>;