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 07:15 PM, Alan Reiner wrote:
> I'll add fuel to the fire here, and express that I believe that
> replace-by-fee is good in the long-term. Peter is not breaking
> the zero-conf, it was already broken, and not admitting it creates
> a false sense of security. I don't want to see systems that are
> built on the assumption that zero-conf tx are safe solely because
> it has always appeared safe. You can argue about rational miner
> behaviors all day, but in a decentralized system you have no idea
> what miners consider rational, or speculate about their incentives.
>
As noted elsewhere in the thread, there are two problems with this
analysis:
1. It asserts that zero-confirmation transactions are in a binary
state of safe/broken instead of recognizing that relying on them is a
non-binary risk analysis on the part of a merchant.
2. Assumptions about what is profitable for miners are based on all
miners having short time horizons for calculating profits.
In addition, I'll add that there is an assumption that honest actors
can not alter their behavior in response to changing conditions.
Since scorched-earth solutions to problems are apparently acceptable
now, what would stop more honest node operators from patching their
nodes to blacklist any peer that relays replace-by-fee transactions,
and maybe even publish an IP address list of those peers?
Punishing Bitcoin users for not adopting somebody's pet solution to a
problem neither responsible nor ethical.
Child-pays-for-parent allows for stuck transactions to be cleared from
the mempool, and allows recipients of zero-conf transactions to adjust
their risk exposure as much or as little as they like.
It's a solution that gives Bitcoin users more freedom, instead of
trying to coerce them into pre-determined directions.
- --
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCAAGBQJU3QA+AAoJECpf2nDq2eYjnagQAJzxQtMMe0ZwAV6UZX+ORrzt
vWh3bfbaO2/NfGL6dXK2i5rWeLTGIkiqZatwaW8S0M53ExMHaqDmW6db6TeE7aDO
hZg4x618FWhYdG7DsfDxThd3rRupSGNJoL3L2763tSz+TrX5HptRh+e8gdy1Sq99
kk1Fyv1jJVBIXBmck19fj0iKOF8rS7n45d4jXO85VF/kfPegslZ7g9lwyH+b/iJ/
F0dfQmMefjEugpSrHww0Dnb4jjoOHz5tdW/Tv5DDNWDmsj/gYAMYRxZvoSl+AvAt
P76odgDUwtbMpb+w3skLRLJCcBuTpSlmYVIhp5YlBrpc9ibznxGe+T3BfYoVGKvh
pz/AxsLcNW3Wc0l0zOHdzoOj4lHjQ/WjJGC/dujnYlZozN+7nuU/GTuSR1GpMxg5
sOM3RuE/Fd+/JII7k7+zMNore44X0p/QVko8OK3kVVPx02Pu1PxRWNHJ2DMY0p7f
b1nsVU5i/853sUez7SyBz5oaNgCgsz4lDKw++TeXhrD6gkdi0LMVOEUjIGMyTZwd
j1wfdfdhhPakcDuyl0ybd9SpSgsUmXkU7N2nkpG8MxMdbopqIhACknZZOrXgoJqL
LtbP1O6v8wvbsdeEH7cXJJhi1IBJK28dv0aBLN6fcqukP23s//Qe+5hhX5nNeUg0
F9dKdL5zCGofvU/U5BVq
=kEMr
-----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/3b3f9a5d/attachment.bin>;
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 02/12/2015 07:15 PM, Alan Reiner wrote:
> I'll add fuel to the fire here, and express that I believe that
> replace-by-fee is good in the long-term. Peter is not breaking
> the zero-conf, it was already broken, and not admitting it creates
> a false sense of security. I don't want to see systems that are
> built on the assumption that zero-conf tx are safe solely because
> it has always appeared safe. You can argue about rational miner
> behaviors all day, but in a decentralized system you have no idea
> what miners consider rational, or speculate about their incentives.
>
As noted elsewhere in the thread, there are two problems with this
analysis:
1. It asserts that zero-confirmation transactions are in a binary
state of safe/broken instead of recognizing that relying on them is a
non-binary risk analysis on the part of a merchant.
2. Assumptions about what is profitable for miners are based on all
miners having short time horizons for calculating profits.
In addition, I'll add that there is an assumption that honest actors
can not alter their behavior in response to changing conditions.
Since scorched-earth solutions to problems are apparently acceptable
now, what would stop more honest node operators from patching their
nodes to blacklist any peer that relays replace-by-fee transactions,
and maybe even publish an IP address list of those peers?
Punishing Bitcoin users for not adopting somebody's pet solution to a
problem neither responsible nor ethical.
Child-pays-for-parent allows for stuck transactions to be cleared from
the mempool, and allows recipients of zero-conf transactions to adjust
their risk exposure as much or as little as they like.
It's a solution that gives Bitcoin users more freedom, instead of
trying to coerce them into pre-determined directions.
- --
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCAAGBQJU3QA+AAoJECpf2nDq2eYjnagQAJzxQtMMe0ZwAV6UZX+ORrzt
vWh3bfbaO2/NfGL6dXK2i5rWeLTGIkiqZatwaW8S0M53ExMHaqDmW6db6TeE7aDO
hZg4x618FWhYdG7DsfDxThd3rRupSGNJoL3L2763tSz+TrX5HptRh+e8gdy1Sq99
kk1Fyv1jJVBIXBmck19fj0iKOF8rS7n45d4jXO85VF/kfPegslZ7g9lwyH+b/iJ/
F0dfQmMefjEugpSrHww0Dnb4jjoOHz5tdW/Tv5DDNWDmsj/gYAMYRxZvoSl+AvAt
P76odgDUwtbMpb+w3skLRLJCcBuTpSlmYVIhp5YlBrpc9ibznxGe+T3BfYoVGKvh
pz/AxsLcNW3Wc0l0zOHdzoOj4lHjQ/WjJGC/dujnYlZozN+7nuU/GTuSR1GpMxg5
sOM3RuE/Fd+/JII7k7+zMNore44X0p/QVko8OK3kVVPx02Pu1PxRWNHJ2DMY0p7f
b1nsVU5i/853sUez7SyBz5oaNgCgsz4lDKw++TeXhrD6gkdi0LMVOEUjIGMyTZwd
j1wfdfdhhPakcDuyl0ybd9SpSgsUmXkU7N2nkpG8MxMdbopqIhACknZZOrXgoJqL
LtbP1O6v8wvbsdeEH7cXJJhi1IBJK28dv0aBLN6fcqukP23s//Qe+5hhX5nNeUg0
F9dKdL5zCGofvU/U5BVq
=kEMr
-----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/3b3f9a5d/attachment.bin>;