Why Nostr? What is Njump?

Dave Smith [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2011-06-14 to 2011-06-14
💬 Posted a total of 1 messages
📚 Participated in the following categories:
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub15dqslu6gl5ttnlxm3wr4v3kazhuc0k4l4m382qzrxs8jjretn8fsrrcn4y

Profile Code

nprofile1qqs2xsg07dy0694elndchp6kgmw3t7v8m2l6acn4qppngrefpu4en5cprpmhxue69uhhyetvv9ujumn0wdmksetjv5hxxmmdqyt8wumn8ghj7un9d3shjtnwdaehgu3wvfskueqw6yrdc

Publishing to

relay.noswhere.com

relay.nostr.band

Author Public Key

npub15dqslu6gl5ttnlxm3wr4v3kazhuc0k4l4m382qzrxs8jjretn8fsrrcn4y

Show more details

Last Notes

2023-06-07 01:55:22

- reply

📅 Original date posted:2011-06-14
🗒️ Summary of this message: Bitcoin's flood control limit based on block size is causing scalability issues, with solutions including raising the limit or lowering the batch size.
📝 Original message:Does it make more sense to have the flood limit based on size in bytes
versus # of blocks?
(I'm a n00b, so pardon my ignorance). :)
D.
On Tue, Jun 14, 2011 at 10:44 AM, Mike Hearn <mike at plan99.net> wrote:
> Block sizes have started to get quite large once again. Whilst testing
> chain download today I was disconnected due to going over the 10mb
> flood control limit. Infuriatingly, I can't reproduce this reliably.
> But at 500 blocks an average of 20kb per block will cause this. As we
> can see from the block explorer, the average is probably quite close
> to that.
>
> The flood control seems like a pretty serious scalability limitation.
> I can see a few solutions. One is to raise the limit again. Another is
> to raise the limit and simultaneously lower the batch size. 500 blocks
> in one message means very large messages no matter how big the flood
> control limit is. Going down to 100 or even 50 would hurt chain
> download speed quite a bit in high latency environments, but chain
> download is already a serious bottleneck.
>
> Thoughts?
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 01:37:16

- reply

📅 Original date posted:2011-06-14
🗒️ Summary of this message: Bitcoin's flood control limit based on block size is causing scalability issues, with solutions including raising the limit or lowering the batch size.
📝 Original message:Does it make more sense to have the flood limit based on size in bytes
versus # of blocks?
(I'm a n00b, so pardon my ignorance). :)
D.
On Tue, Jun 14, 2011 at 10:44 AM, Mike Hearn <mike at plan99.net> wrote:
> Block sizes have started to get quite large once again. Whilst testing
> chain download today I was disconnected due to going over the 10mb
> flood control limit. Infuriatingly, I can't reproduce this reliably.
> But at 500 blocks an average of 20kb per block will cause this. As we
> can see from the block explorer, the average is probably quite close
> to that.
>
> The flood control seems like a pretty serious scalability limitation.
> I can see a few solutions. One is to raise the limit again. Another is
> to raise the limit and simultaneously lower the batch size. 500 blocks
> in one message means very large messages no matter how big the flood
> control limit is. Going down to 100 or even 50 would hurt chain
> download speed quite a bit in high latency environments, but chain
> download is already a serious bottleneck.
>
> Thoughts?
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 01:20:05

- reply

📅 Original date posted:2011-06-14
🗒️ Summary of this message: Bitcoin's flood control limit based on block size is causing scalability issues, with solutions including raising the limit or lowering the batch size.
📝 Original message:Does it make more sense to have the flood limit based on size in bytes
versus # of blocks?
(I'm a n00b, so pardon my ignorance). :)
D.
On Tue, Jun 14, 2011 at 10:44 AM, Mike Hearn <mike at plan99.net> wrote:
> Block sizes have started to get quite large once again. Whilst testing
> chain download today I was disconnected due to going over the 10mb
> flood control limit. Infuriatingly, I can't reproduce this reliably.
> But at 500 blocks an average of 20kb per block will cause this. As we
> can see from the block explorer, the average is probably quite close
> to that.
>
> The flood control seems like a pretty serious scalability limitation.
> I can see a few solutions. One is to raise the limit again. Another is
> to raise the limit and simultaneously lower the batch size. 500 blocks
> in one message means very large messages no matter how big the flood
> control limit is. Going down to 100 or even 50 would hurt chain
> download speed quite a bit in high latency environments, but chain
> download is already a serious bottleneck.
>
> Thoughts?
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 01:20:05

- reply

📅 Original date posted:2011-06-14
🗒️ Summary of this message: Bitcoin's flood control limit based on block size is causing scalability issues, with solutions including raising the limit or lowering the batch size.
📝 Original message:Does it make more sense to have the flood limit based on size in bytes
versus # of blocks?
(I'm a n00b, so pardon my ignorance). :)
D.
On Tue, Jun 14, 2011 at 10:44 AM, Mike Hearn <mike at plan99.net> wrote:
> Block sizes have started to get quite large once again. Whilst testing
> chain download today I was disconnected due to going over the 10mb
> flood control limit. Infuriatingly, I can't reproduce this reliably.
> But at 500 blocks an average of 20kb per block will cause this. As we
> can see from the block explorer, the average is probably quite close
> to that.
>
> The flood control seems like a pretty serious scalability limitation.
> I can see a few solutions. One is to raise the limit again. Another is
> to raise the limit and simultaneously lower the batch size. 500 blocks
> in one message means very large messages no matter how big the flood
> control limit is. Going down to 100 or even 50 would hurt chain
> download speed quite a bit in high latency environments, but chain
> download is already a serious bottleneck.
>
> Thoughts?
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>