📅 Original date posted:2015-06-30
📝 Original message:On Tue, Jun 30, 2015 at 09:49:51AM -0400, Chris Pacia wrote:
>
>
> On 06/30/2015 09:12 AM, Adam Back wrote:
> > It is correct to view first-seen miner and relay policy as
> > honour-based, though it is the current default.
> >
> >
> What would be the effect of IBLT on the first seen policy? It seems that
> if a miner has to broadcast extra data with his blocks because he's
> using full RBF and everyone else is using first-seen then his blocks are
> at a disadvantage in terms of propagation. That wouldn't make first-seen
> a hard consensus rule, but rather one rational miners are likely to
> follow. Or is this effect likely to be minimal?
The disadvantage can be calculated compensated for by higher fees; if
the disadvantage is so large that the higher fees are unaffordable we're
in big trouble as the guarantees that mempools are in sync are pretty
poor. (why doublespending zeroconf txs is easy!) For instance, that'd
imply that sending two simultaneous transactions will cause profit
losses to all but the largest miners - who are unaffected - and that
upgrades that change IsStandard() will cause profit losses, among many
other problems.
Bitcoin just doesn't work if blocks aren't relayed quickly in the worst
case.
--
'peter'[:-1]@petertodd.org
00000000000000000c51793e1f2f6b9bd82dd1579b3e4207e70a0aa8fb953c80
-------------- 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/20150630/41ecd7c1/attachment.sig>;
Peter Todd [ARCHIVE] /
npub1m2…a2np2
2023-06-07 15:41:15
in reply to nevent1q…jkne
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Published at
2023-06-07 15:41:15Event JSON
{
"id": "da0d243ae90ca1f1470fc224e525ec50971f43da68217515d6edde75b3f5c1aa",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1686152475,
"kind": 1,
"tags": [
[
"e",
"8a75acfffe44f9748a902379feb70f856b01a438a0303ea9088c6c0d7a3ff10d",
"",
"root"
],
[
"e",
"283eb79e0aa7c4743dc4f7ba25389dc147f5f95471a54c0fe873a29d7bb826aa",
"",
"reply"
],
[
"p",
"905f29cc0a91b1227b531ae8d8419b0926baa4a18373f0c58693c8f32c26ffa4"
]
],
"content": "📅 Original date posted:2015-06-30\n📝 Original message:On Tue, Jun 30, 2015 at 09:49:51AM -0400, Chris Pacia wrote:\n\u003e \n\u003e \n\u003e On 06/30/2015 09:12 AM, Adam Back wrote:\n\u003e \u003e It is correct to view first-seen miner and relay policy as\n\u003e \u003e honour-based, though it is the current default.\n\u003e \u003e\n\u003e \u003e\n\u003e What would be the effect of IBLT on the first seen policy? It seems that\n\u003e if a miner has to broadcast extra data with his blocks because he's\n\u003e using full RBF and everyone else is using first-seen then his blocks are\n\u003e at a disadvantage in terms of propagation. That wouldn't make first-seen\n\u003e a hard consensus rule, but rather one rational miners are likely to\n\u003e follow. Or is this effect likely to be minimal?\n\nThe disadvantage can be calculated compensated for by higher fees; if\nthe disadvantage is so large that the higher fees are unaffordable we're\nin big trouble as the guarantees that mempools are in sync are pretty\npoor. (why doublespending zeroconf txs is easy!) For instance, that'd\nimply that sending two simultaneous transactions will cause profit\nlosses to all but the largest miners - who are unaffected - and that\nupgrades that change IsStandard() will cause profit losses, among many\nother problems.\n\nBitcoin just doesn't work if blocks aren't relayed quickly in the worst\ncase.\n\n-- \n'peter'[:-1]@petertodd.org\n00000000000000000c51793e1f2f6b9bd82dd1579b3e4207e70a0aa8fb953c80\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 650 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150630/41ecd7c1/attachment.sig\u003e",
"sig": "0fd7fc93b542a5828589f752913520728d1cc7641f9a31d807ac19d790940152b2614aee1fd59fc2ea57ba7a4787aef076fbfcd138c0e62744dfb8ba0fa22789"
}