📅 Original date posted:2021-12-18
📝 Original message:It's not exactly what you're looking for but this is very similar to the
premise of Bobtail, which was presented at Scaling Bitcoin a few years ago:
https://arxiv.org/abs/1709.08750
On Fri, Dec 17, 2021, 10:54 Jeremy via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> An interesting concept occurred to me today while chatting with Nic Carter.
>
> If we set Bitcoin Core up to gossip headers for work shares (e.g.,
> expected 500 headers per block would have 20kb overhead, assuming we don't
> need to send the prev hash) we'd be able to have more accurate finality
> estimates and warnings if we see hashrate abandoning our chain tip. This is
> observable regardless of if dishonest miners choose not to publish their
> work on non tip shares, since you can notice the missing work.
>
> In the GUI, we could give users an additional warning if they are
> accepting a payment during a sudden hashrate decrease that they might wait
> longer.
>
> Has this been discussed before?
>
> Cheers,
>
> Jeremy
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>;
> <https://twitter.com/JeremyRubin>;
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211218/422c0b92/attachment.html>;
Newsletter Catcher [ARCHIVE] /
npub1xx…xyq0j
2023-06-07 23:01:34
in reply to nevent1q…fep9
Author Public Key
npub1xxslhyqu8mvfws856pldewenyyc0pwjq2ywrh7wrmz5y39cs2qlsmxyq0jPublished at
2023-06-07 23:01:34Event JSON
{
"id": "618f7e520a49e310b471e1fe0f6978cf0b186c921208d339eeb3d3af341a94f2",
"pubkey": "31a1fb901c3ed89740f4d07edcbb332130f0ba40511c3bf9c3d8a8489710503f",
"created_at": 1686178894,
"kind": 1,
"tags": [
[
"e",
"4f2692bf9e3f833b5f23a61852be93341137cbe97d36df3954c96d4f517080c0",
"",
"root"
],
[
"e",
"07742e0761aadb61f5f59d5f6ad1d733f9fc1d4f27315beeba269ee5e9688b42",
"",
"reply"
],
[
"p",
"01f53a3166b3b23139201763777e070fcfed5555ad7555f7e90114c0c9e0e8b4"
]
],
"content": "📅 Original date posted:2021-12-18\n📝 Original message:It's not exactly what you're looking for but this is very similar to the\npremise of Bobtail, which was presented at Scaling Bitcoin a few years ago:\nhttps://arxiv.org/abs/1709.08750\n\nOn Fri, Dec 17, 2021, 10:54 Jeremy via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e An interesting concept occurred to me today while chatting with Nic Carter.\n\u003e\n\u003e If we set Bitcoin Core up to gossip headers for work shares (e.g.,\n\u003e expected 500 headers per block would have 20kb overhead, assuming we don't\n\u003e need to send the prev hash) we'd be able to have more accurate finality\n\u003e estimates and warnings if we see hashrate abandoning our chain tip. This is\n\u003e observable regardless of if dishonest miners choose not to publish their\n\u003e work on non tip shares, since you can notice the missing work.\n\u003e\n\u003e In the GUI, we could give users an additional warning if they are\n\u003e accepting a payment during a sudden hashrate decrease that they might wait\n\u003e longer.\n\u003e\n\u003e Has this been discussed before?\n\u003e\n\u003e Cheers,\n\u003e\n\u003e Jeremy\n\u003e\n\u003e --\n\u003e @JeremyRubin \u003chttps://twitter.com/JeremyRubin\u003e\n\u003e \u003chttps://twitter.com/JeremyRubin\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211218/422c0b92/attachment.html\u003e",
"sig": "d0b9f7b0909fee6e5bde4ab50779457d35e346e1731287c52f0b90829b4e6f4197ee5d7fdea871516436bcf4c2cfd44daba63c502ef2688da3fb1eadfb66e102"
}