📅 Original date posted:2011-11-23
🗒️ Summary of this message: A method for adjusting difficulty in a power drop is needed, but using synchronized time windows and selecting the hardest block is complicated. The delay in propagation will also cause forks.
📝 Original message:First of all I do agree that a method for adjusting the difficulty in a
huge power drop is needed (I don't see it so much in power rises).
The current block generation with a fixed difficulty was chosen because it
it clear when to adjust and to what target difficulty it has to be
adjusted. If we were to use synchronized time windows and select the
hardest block it gets incredibly complicated as synchronization is not
possible in distributed systems. Even the smallest drift would allow for
forks in the chain all over the place. Furthermore the delay in propagation
will also cause forks.
If 1/2 of the network see one block as the hardest, and for the rest of the
network it came too late then we'll have a fork that stays with us quite a
while.
The block chain is described as a timestamp server in the paper, but it is
more of a proof-of-existence before, as the contained timestamp cannot be
trusted anyway.
Regards,
Chris
2011/11/23 Jorge Timón <timon.elviejo at gmail.com>
> With the current system, the timestamp can also be cheated, but miners
> have no direct incentive to do it. With your system, they increase
> their probability of mining a block by putting a false timestamp.
> Also, where's the network clock you're talking about? Isn't it the
> timestamps in the blockchain?
>
>
>
> 2011/11/23, Andy Parkins <andyparkins at gmail.com>:
> > On 2011 November 23 Wednesday, Jorge Timón wrote:
> >> 2011/11/23, Andy Parkins <andyparkins at gmail.com>:
> >> > Let's abandon the idea of a target difficulty. Instead, every node
> just
> >> >
> >> > generates the most difficulty block it can. Simultaneously, every
> node
> >> > is listening for "the most difficult block generated before time T";
> >> > with T being
> >> > picked to be the block generation rate (10 minutes).
> >>
> >> A miner could try to obtain more difficulty out of time and cheat its
> >> reported datetime (T).
> >
> > Just as with the current system.
> >
> > The defence is that on receipt of a block, its timestamp is checked
> against
> > the node's own clock and averaged network clock. Blocks out of that band
> > are
> > rejected.
> >
> >
> > Andy
> > --
> > Dr Andy Parkins
> > andyparkins at gmail.com
> >
>
>
> --
> Jorge Timón
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111123/1d2aa84d/attachment.html>;
Christian Decker [ARCHIVE] /
npub1wt…gtuyn
2023-06-07 02:41:10
in reply to nevent1q…kupc
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-07 02:41:10Event JSON
{
"id": "f63ebe0af77ebec39e5fc58dacb33444c0942581b22230497e24f64460ff3e8d",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686105670,
"kind": 1,
"tags": [
[
"e",
"2046d4dc725b4ce8920d2c47249dd7dad0c6e38daddd7a5e99f03e9b24dd8e66",
"",
"root"
],
[
"e",
"cdc8f9a70d5dd858b263f72b500acd171b0d7dcba38286bd9d672bf70a704cc4",
"",
"reply"
],
[
"p",
"498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84"
]
],
"content": "📅 Original date posted:2011-11-23\n🗒️ Summary of this message: A method for adjusting difficulty in a power drop is needed, but using synchronized time windows and selecting the hardest block is complicated. The delay in propagation will also cause forks.\n📝 Original message:First of all I do agree that a method for adjusting the difficulty in a\nhuge power drop is needed (I don't see it so much in power rises).\n\nThe current block generation with a fixed difficulty was chosen because it\nit clear when to adjust and to what target difficulty it has to be\nadjusted. If we were to use synchronized time windows and select the\nhardest block it gets incredibly complicated as synchronization is not\npossible in distributed systems. Even the smallest drift would allow for\nforks in the chain all over the place. Furthermore the delay in propagation\nwill also cause forks.\n\nIf 1/2 of the network see one block as the hardest, and for the rest of the\nnetwork it came too late then we'll have a fork that stays with us quite a\nwhile.\n\nThe block chain is described as a timestamp server in the paper, but it is\nmore of a proof-of-existence before, as the contained timestamp cannot be\ntrusted anyway.\n\nRegards,\nChris\n\n2011/11/23 Jorge Timón \u003ctimon.elviejo at gmail.com\u003e\n\n\u003e With the current system, the timestamp can also be cheated, but miners\n\u003e have no direct incentive to do it. With your system, they increase\n\u003e their probability of mining a block by putting a false timestamp.\n\u003e Also, where's the network clock you're talking about? Isn't it the\n\u003e timestamps in the blockchain?\n\u003e\n\u003e\n\u003e\n\u003e 2011/11/23, Andy Parkins \u003candyparkins at gmail.com\u003e:\n\u003e \u003e On 2011 November 23 Wednesday, Jorge Timón wrote:\n\u003e \u003e\u003e 2011/11/23, Andy Parkins \u003candyparkins at gmail.com\u003e:\n\u003e \u003e\u003e \u003e Let's abandon the idea of a target difficulty. Instead, every node\n\u003e just\n\u003e \u003e\u003e \u003e\n\u003e \u003e\u003e \u003e generates the most difficulty block it can. Simultaneously, every\n\u003e node\n\u003e \u003e\u003e \u003e is listening for \"the most difficult block generated before time T\";\n\u003e \u003e\u003e \u003e with T being\n\u003e \u003e\u003e \u003e picked to be the block generation rate (10 minutes).\n\u003e \u003e\u003e\n\u003e \u003e\u003e A miner could try to obtain more difficulty out of time and cheat its\n\u003e \u003e\u003e reported datetime (T).\n\u003e \u003e\n\u003e \u003e Just as with the current system.\n\u003e \u003e\n\u003e \u003e The defence is that on receipt of a block, its timestamp is checked\n\u003e against\n\u003e \u003e the node's own clock and averaged network clock. Blocks out of that band\n\u003e \u003e are\n\u003e \u003e rejected.\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e Andy\n\u003e \u003e --\n\u003e \u003e Dr Andy Parkins\n\u003e \u003e andyparkins at gmail.com\n\u003e \u003e\n\u003e\n\u003e\n\u003e --\n\u003e Jorge Timón\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e All the data continuously generated in your IT infrastructure\n\u003e contains a definitive record of customers, application performance,\n\u003e security threats, fraudulent activity, and more. Splunk takes this\n\u003e data and makes sense of it. IT sense. And common sense.\n\u003e http://p.sf.net/sfu/splunk-novd2d\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111123/1d2aa84d/attachment.html\u003e",
"sig": "4ef3178845eb2bd8f47618231800c932ccd8c512f4812bd701d3661ce28a9c74e42bbc1b8d628708d35f5a26af5f128fcd775d914935bbafe6cf091efccbe779"
}