Adam Back [ARCHIVE] on Nostr: 📅 Original date posted:2015-06-30 📝 Original message:It is correct to view ...
📅 Original date posted:2015-06-30
📝 Original message:It is correct to view first-seen miner and relay policy as
honour-based, though it is the current default.
I think it would be better to deploy full-RBF in an opt-in way and
leave the current default miner & relay policies as is. So for
example a new signature flag or transaction type that is marked as
opting-in waiving the first-seen policy.
In this way we can get a smoother transition for people away from the
first-seen assumption, towards greenaddress (trust based) and
lightning / payment channel solutions. Mid-term the channel and hub
model can provide fast secure 0-confirm transactions, which are
generically not known to be directly and robustly securable via miner
consensus.
As we've seen abruptly stopping the first-seen miner & relay policy is
risky and unpopular and causes people to seek contracts with miners to
retain first-seen. This is itself a bad trend for fungibility for
obvious reasons.
We shouldn't prejudge people's and segment's of business weak-reliance
on first-seen. Some types of payments are generally high trust (known
relationships) or physical stores or very low marginal cost (coffee
marginal cost <10c, sale price > $2 or lower ebook, audio stream etc
as embodied by fremium model). It is not ours to prejudge and kill
their business. It our job to help improve network security however,
so that they do not have to eat a fraud cost. And that is do able
with trust via greenaddress, or without trust (other than
time-preference) via the hub & channel model.
Security maybe incrementally improvable via non-spendable relaying of
proof of double-spent status, and services that try to measure % of
miners by hashrate with assumption of first-seen that have have seen a
given transaction first, though I am not sure such approaches are
robust enough to invest time in vs greenaddress or hub & channel.
Any thoughts on the simplest way to support an opt-in version of full-RBF?
Adam
On 30 June 2015 at 03:37, Peter Todd <pete at petertodd.org> wrote:
> 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
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
📝 Original message:It is correct to view first-seen miner and relay policy as
honour-based, though it is the current default.
I think it would be better to deploy full-RBF in an opt-in way and
leave the current default miner & relay policies as is. So for
example a new signature flag or transaction type that is marked as
opting-in waiving the first-seen policy.
In this way we can get a smoother transition for people away from the
first-seen assumption, towards greenaddress (trust based) and
lightning / payment channel solutions. Mid-term the channel and hub
model can provide fast secure 0-confirm transactions, which are
generically not known to be directly and robustly securable via miner
consensus.
As we've seen abruptly stopping the first-seen miner & relay policy is
risky and unpopular and causes people to seek contracts with miners to
retain first-seen. This is itself a bad trend for fungibility for
obvious reasons.
We shouldn't prejudge people's and segment's of business weak-reliance
on first-seen. Some types of payments are generally high trust (known
relationships) or physical stores or very low marginal cost (coffee
marginal cost <10c, sale price > $2 or lower ebook, audio stream etc
as embodied by fremium model). It is not ours to prejudge and kill
their business. It our job to help improve network security however,
so that they do not have to eat a fraud cost. And that is do able
with trust via greenaddress, or without trust (other than
time-preference) via the hub & channel model.
Security maybe incrementally improvable via non-spendable relaying of
proof of double-spent status, and services that try to measure % of
miners by hashrate with assumption of first-seen that have have seen a
given transaction first, though I am not sure such approaches are
robust enough to invest time in vs greenaddress or hub & channel.
Any thoughts on the simplest way to support an opt-in version of full-RBF?
Adam
On 30 June 2015 at 03:37, Peter Todd <pete at petertodd.org> wrote:
> 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
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>