📅 Original date posted:2015-06-29
📝 Original message:Den 30 jun 2015 02:21 skrev "Tom Harding" <tomh at thinlink.com>:
>
> 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.
What you are asking for is TSA style reactive security and unverifiable and
fundamentally untrustable security mechanisms, rejecting proactive security
on the grounds that it is inconvenient.
What you ask to see implemented will trivially fall to a sybil attack. It
isn't securable. It is running on the honor system exclusively. It will be
attacked, it will fail, losses will be had, the attackers will walk away
with embarrassingly large sums.
You want verifiable behavior? Incentives to tell the truth? Incentives to
be consistent? Multisignature notaries (Greenaddress.it), payment channel
based hub-and-spokes (LN, Stroem), etc... Trusting the P2P network is
futile. You need one accountable party that is actually capable of
enforcing the behavior you ask for, one that can build a reputation over
time - the P2P nodes you wish to hold accountable are on the other hand
powerless to stop an actual attack, their reputations are therefore
meaningless and irrelevant. Multisignature notaries aren't, as they can
stop an attack, and they can be sued for breach of contract if they don't -
neither of those applies to P2P nodes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150630/725125ab/attachment.html>;
Natanael [ARCHIVE] /
npub179…lpmjt
2023-06-07 15:41:13
in reply to nevent1q…vmnv
Author Public Key
npub1798ncudyucap9jzzujjsgufx8tdykm8auzfledjcs6f6wf4ekqvq8lpmjtPublished at
2023-06-07 15:41:13Event JSON
{
"id": "17702926deabbaa1665928a3a5f401d4c7731423c796f985b525712e13580992",
"pubkey": "f14f3c71a4e63a12c842e4a50471263ada4b6cfde093fcb6588693a726b9b018",
"created_at": 1686152473,
"kind": 1,
"tags": [
[
"e",
"8a75acfffe44f9748a902379feb70f856b01a438a0303ea9088c6c0d7a3ff10d",
"",
"root"
],
[
"e",
"afeeb32eaa22fa0d1c297bdc54950f316dc4456a8b3071b561e2d3cc9d280af4",
"",
"reply"
],
[
"p",
"dc329a02c970aabf03b87185ef51c86afe4586fe3a148508af898af3fabc56a3"
]
],
"content": "📅 Original date posted:2015-06-29\n📝 Original message:Den 30 jun 2015 02:21 skrev \"Tom Harding\" \u003ctomh at thinlink.com\u003e:\n\u003e\n\u003e On 6/28/2015 10:07 PM, Peter Todd wrote:\n\u003e\u003e\n\u003e\u003e Worryingly large payment providers have shown\n\u003e\u003e willingness(4) to consider extreme measures such as entering into legal\n\u003e\u003e contracts directly with large miners to ensure their transactions get\nmined.\n\u003e\u003e This is a significant centralization risk and it is not practical or even\n\u003e\u003e possible for small miners to enter into these contracts, leading to a\nsituation\n\u003e\u003e where moving your hashing power to a larger pool will result in higher\nprofits\n\u003e\u003e from hashing power contracts; if these payment providers secure a\nmajority of\n\u003e\u003e hashing power with these contracts inevitably there will be a temptation\nto\n\u003e\u003e kick non-compliant miners off the network entirely with a 51% attack.\n\u003e\u003e\n\u003e\n\u003e Your incomprehensible meddling with successful usage patterns threatens\nto have unintended consequences directly in opposition to your own stated\ngoal of decentralization. And yet you persist.\n\u003e\n\u003e As we deliberately break things and turn the P2P network into a\ncompletely unpredictable hodge-podge of relay policies, we should expect\nmany more participants to bypass the P2P network entirely.\n\nWhat you are asking for is TSA style reactive security and unverifiable and\nfundamentally untrustable security mechanisms, rejecting proactive security\non the grounds that it is inconvenient.\n\nWhat you ask to see implemented will trivially fall to a sybil attack. It\nisn't securable. It is running on the honor system exclusively. It will be\nattacked, it will fail, losses will be had, the attackers will walk away\nwith embarrassingly large sums.\n\nYou want verifiable behavior? Incentives to tell the truth? Incentives to\nbe consistent? Multisignature notaries (Greenaddress.it), payment channel\nbased hub-and-spokes (LN, Stroem), etc... Trusting the P2P network is\nfutile. You need one accountable party that is actually capable of\nenforcing the behavior you ask for, one that can build a reputation over\ntime - the P2P nodes you wish to hold accountable are on the other hand\npowerless to stop an actual attack, their reputations are therefore\nmeaningless and irrelevant. Multisignature notaries aren't, as they can\nstop an attack, and they can be sued for breach of contract if they don't -\nneither of those applies to P2P nodes.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150630/725125ab/attachment.html\u003e",
"sig": "fb693caf472e72332a53dc96035c0d076d5daf0efb083d7186361271962c80e44de611d8797afd3e310bf02a8aa744fac2599609294b3b65f15d5be6cb0e1223"
}