Peter Todd [ARCHIVE] on Nostr: 📅 Original date posted:2015-06-29 📝 Original message:On Mon, Jun 29, 2015 at ...
📅 Original date posted:2015-06-29
📝 Original message:On Mon, Jun 29, 2015 at 05:21:35PM -0700, Tom Harding wrote:
> On 6/28/2015 10:07 PM, Peter Todd wrote:
> >Worryingly large payment providers have shown
> >willingness(4) to consider extreme measures such as entering into legal
> >contracts directly with large miners to ensure their transactions get mined.
> >This is a significant centralization risk and it is not practical or even
> >possible for small miners to enter into these contracts, leading to a situation
> >where moving your hashing power to a larger pool will result in higher profits
> >from hashing power contracts; if these payment providers secure a majority of
> >hashing power with these contracts inevitably there will be a temptation to
> >kick non-compliant miners off the network entirely with a 51% attack.
> >
>
> Your incomprehensible meddling with successful usage patterns
> threatens to have unintended consequences directly in opposition to
> your own stated goal of decentralization. And yet you persist.
>
> As we deliberately break things and turn the P2P network into a
> completely unpredictable hodge-podge of relay policies, we should
> expect many more participants to bypass the P2P network entirely.
>
> Many of the pieces are already in place.
>
> If we wanted the P2P network to have more predicable behavior, it
> would be possible for nodes to provide incentives to their
> neighbors. For example, if you had a pair of nodes, you could test
> your peers to see that they actually do relay "standard"
> transactions. This would have emergent usability benefits for the
> P2P network as a whole.
To be clear, full-RBF is a change that broadens what the P2P network
relays - transactions previously not relayed are now relayed. Under no
circumstance will full-RBF result in transactions *not* being relayed
that previously were relayed. This makes the P2P network more useful
rather than less, as it gives a predictable and uniform method to get
transactions to a wider variety of miners with a wider variety of
policies.
Note how even if no miners ever supported full-RBF, supporting full-RBF
on relay nodes would still be useful to users as it provides an easy and
cost-effective mechanism to rebroadcast transactions. In fact,
supporting full-RBF by default and disabling it if getblocktemplate is
called would be reasonable, if more than a bit of a hack!
In any case, my pull-req lets you set -fullrbfactivationtime=0 as a
simple and easy way to disable full-RBF functionality. Miners and relay
nodes who choose not to support it can easily do so, similar to how
OP_RETURN transactions can be disabled with -datacarrier=0
--
'peter'[:-1]@petertodd.org
00000000000000000bfe93181a10e2f12a45da877b5026ae26988e936a1322ae
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150629/3702a32a/attachment.sig>;
📝 Original message:On Mon, Jun 29, 2015 at 05:21:35PM -0700, Tom Harding wrote:
> On 6/28/2015 10:07 PM, Peter Todd wrote:
> >Worryingly large payment providers have shown
> >willingness(4) to consider extreme measures such as entering into legal
> >contracts directly with large miners to ensure their transactions get mined.
> >This is a significant centralization risk and it is not practical or even
> >possible for small miners to enter into these contracts, leading to a situation
> >where moving your hashing power to a larger pool will result in higher profits
> >from hashing power contracts; if these payment providers secure a majority of
> >hashing power with these contracts inevitably there will be a temptation to
> >kick non-compliant miners off the network entirely with a 51% attack.
> >
>
> Your incomprehensible meddling with successful usage patterns
> threatens to have unintended consequences directly in opposition to
> your own stated goal of decentralization. And yet you persist.
>
> As we deliberately break things and turn the P2P network into a
> completely unpredictable hodge-podge of relay policies, we should
> expect many more participants to bypass the P2P network entirely.
>
> Many of the pieces are already in place.
>
> If we wanted the P2P network to have more predicable behavior, it
> would be possible for nodes to provide incentives to their
> neighbors. For example, if you had a pair of nodes, you could test
> your peers to see that they actually do relay "standard"
> transactions. This would have emergent usability benefits for the
> P2P network as a whole.
To be clear, full-RBF is a change that broadens what the P2P network
relays - transactions previously not relayed are now relayed. Under no
circumstance will full-RBF result in transactions *not* being relayed
that previously were relayed. This makes the P2P network more useful
rather than less, as it gives a predictable and uniform method to get
transactions to a wider variety of miners with a wider variety of
policies.
Note how even if no miners ever supported full-RBF, supporting full-RBF
on relay nodes would still be useful to users as it provides an easy and
cost-effective mechanism to rebroadcast transactions. In fact,
supporting full-RBF by default and disabling it if getblocktemplate is
called would be reasonable, if more than a bit of a hack!
In any case, my pull-req lets you set -fullrbfactivationtime=0 as a
simple and easy way to disable full-RBF functionality. Miners and relay
nodes who choose not to support it can easily do so, similar to how
OP_RETURN transactions can be disabled with -datacarrier=0
--
'peter'[:-1]@petertodd.org
00000000000000000bfe93181a10e2f12a45da877b5026ae26988e936a1322ae
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150629/3702a32a/attachment.sig>;