Charlie 'Charles' Shrem [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-05-07 to 2017-07-13
💬 Posted a total of 4 messages
📚 Participated in the following categories: Bitcoin-development, bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 18:04:06

- reply

📅 Original date posted:2017-07-13
📝 Original message:Andrew,
Block 475776 and block 477792 (July 26) are the last 2 difficulty
adjustment periods before Aug 1st.
Charlie
On Thu, Jul 13, 2017 at 3:48 PM, Andrew Chow via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> What's special about block 475776?
>
> On July 13, 2017 12:23:46 PM Sergio Demian Lerner via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> The BIP has been updated.
>>
>> Changes:
>> - The technical spec has been improved: now the block size increase is
>> specified in terms of weight and not in terms of bytes.
>> - The increase in the maximum block sigops after HF has been documented.
>> - Comments added about the worst case block size.
>>
>> Happy weekend! And don't forget to start signaling something before block
>> 475776 ! It's just 90 blocks away.
>> Bit 1 or 4,1 or whatever you wish, but please signal something.
>>
>> To the moon!
>>
>>
>> On Wed, Jul 12, 2017 at 2:38 PM, Jorge Timón via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>>
>>>
>>> On 12 Jul 2017 2:31 pm, "Tom Zander via bitcoin-dev" <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>> On Monday, 10 July 2017 20:38:08 CEST Jorge Timón via bitcoin-dev wrote:
>>> > I think anything less than 1 year after release of tested code by some
>>> > implementation would be irresponsible for any hardfork, even a very
>>> > simple one.
>>>
>>> Good news!
>>>
>>> Code to support 2x (the hard fork part of the proposal) has been out and
>>> tested for much longer than that.
>>>
>>>
>>> Not true. It's different code on top of segwit. The first attempt in
>>> btc1 (very recent) didn't even increased the size (because it changed the
>>> meaningless "base size" without touching the weight limit. As for the
>>> current code, I don't think it has been properly tested today, let alone
>>> "for mucj longer than 1 year.
>>> Anyway, I said, one year from tested release. Segwitx2 hasn't been
>>> released, has it? If so, too late to discuss a bip imo, the bip may end up
>>> being different from what has been released due to feedback (unless it is
>>> ignored again, of course).
>>>
>>>
>>> --
>>> Tom Zander
>>> Blog: https://zander.github.io
>>> Vlog: https://vimeo.com/channels/tomscryptochannel
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
> _______________________________________________
> 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/20170713/6321b907/attachment.html>

2023-06-07 15:22:14

- reply

📅 Original date posted:2014-06-03
📝 Original message:Hey Rusty,
This is intriguing, do you have a writeup somewhere I can read more about ?
Thanks,
Charlie
CharlieShrem.com | *Please **encrypt messages with my PGP key
<http://charlieshrem.com/contact/>*
On Tue, Jun 3, 2014 at 8:45 AM, Rusty Russell <rusty at rustcorp.com.au> wrote:
> Luke Dashjr <luke at dashjr.org> writes:
> > On Tuesday, June 03, 2014 4:29:55 AM xor wrote:
> >> Hi,
> >>
> >> I thought a lot about the worst case scenario of SHA256d being broken
> in a
> >> way which could be abused to
> >> A) reduce the work of mining a block by some significant amount
> >> B) reduce the work of mining a block to zero, i.e. allow instant mining.
> >
> > C) fabricate past blocks entirely.
> >
> > If SHA256d is broken, Bitcoin as it is fails entirely.
>
> I normally just lurk, but I looked at this issue last year, so thought
> I'd chime in. I never finished my paper though...
>
> In the event of an *anticipated* weakening of SHA256, a gradual
> transition is possible which avoids massive financial disruption.
>
> My scheme used a similar solve-SHA256-then-solve-SHA3 (requiring an
> extra nonce for the SHA3), with the difficulty of SHA256 ramping down
> and SHA3 ramping up over the transition (eg for a 1 year transition,
> start with 25/26 SHA2 and 1/26 SHA3).
>
> The hard part is to estimate what the SHA3 difficulty should be over
> time. My solution was to adjust only the SHA3 target on every *second*
> difficulty change (otherwise assume that SHA2 and SHA3 have equally
> changed rate and adjust targets on both).
>
> This works reasonably well even if the initial SHA3 difficulty is way
> off, and also if SHA2 breaks completely halfway through the transition.
>
> I can provide more details if anyone is interested.
>
> Cheers,
> Rusty.
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> 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/20140603/1b65e2fd/attachment.html>

2023-06-07 15:21:07

- reply

📅 Original date posted:2014-05-07
📝 Original message:For those who are interested, here is my 9 step way to install a full node.
I tried to make it as universal as possible.
http://charlieshrem.com/node/
Thanks,
Charlie
CharlieShrem.com | *Please **encrypt messages with my PGP key
<http://charlieshrem.com/contact/>*
On Wed, May 7, 2014 at 4:35 PM, Jameson Lopp <jameson.lopp at gmail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> The charts are generated on-demand by Graphite, which is a Django app.
>
> I will note that one reason I chose StatsD is because it sends the stats
> via UDP rather than TCP, which is a non-blocking operation. I didn't want
> the sending of stats to affect the node's performance.
>
> - - Jameson
>
> On 05/07/2014 04:18 PM, Wladimir wrote:
> > On Wed, May 7, 2014 at 9:57 PM, Jameson Lopp <jameson.lopp at gmail.com>
> wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> I agree that it would be awesome to offer these types of stats with the
> installer; unfortunately the route I've taken has dependencies on several
> other other pieces of software to do all the heavy lifting of stats
> aggregation and chart rendering. I'm assuming that you would not want to
> build any of that processing into Bitcoin Core itself; would you be opposed
> to packaging other software along with the installer?
> >
> > Depends on just how much stuff it is. The idea is primarily to have an
> > installer for running a (wallet-less) node as an OS background
> > service.
> >
> > Having some statistics available would be worth some extra download
> > size, otherwise it would be pretty much invisible.
> >
> > We'd already decided that we would need something like Python for the
> > stats service. Implementing things like web services in C++ is just
> > not realistic given the time constraints and the great already-written
> > code that is out there. As an optional tool it should be external, not
> > part of bitcoind itself.
> >
> > I suppose the chart rendering happens client-side? In that case the
> > web service just has to collect and provide the data, and serve static
> > html/js files.
> >
> > Wladimir
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJTapj5AAoJEIch3FSFNiDcofAIALHi7XgQi8pf75btujaeBsX3
> nniRD0yZIkoAvPlvFLiKQGE8TH+VR8Sb9fQACzmajYx1yjD0gN4xvkJXbI+pkeP5
> L8ZryhqxL5qCh/OI4+fkWlsp5Nwx89QvUepdXXdc/AQGQJIEMceiZOLDcjbk29Yb
> vCsyJL5yhzM9BM0cImuvrOBPtF3/L6DbgHP8OLD2LHRl4paJ1UDtfYCx3HVO9wp8
> ZWq1oCaFyoYmUyx8GTUzbLjh9sOgaq43GKYec/kQSLmFxhhMF0dGNDMiwD/xz1i7
> LIswjlEKHZYOWWL3SMQg3pLlOTzGH4mHg++BAyrtzZ5CHlc1rjsPSk2d2Df/8Zc=
> =GFu9
> -----END PGP SIGNATURE-----
>
>
> ------------------------------------------------------------------------------
> Is your legacy SCM system holding you back? Join Perforce May 7 to find
> out:
>  3 signs your SCM is hindering your productivity
>  Requirements for releasing software faster
>  Expert tips and advice for migrating your SCM now
> http://p.sf.net/sfu/perforce
> _______________________________________________
> 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/20140507/a3cd38d2/attachment.html>

2023-06-07 15:21:05

- reply

📅 Original date posted:2014-05-07
📝 Original message:I'm going to install this now on my full node, looks really cool!
This is my node page: http://199.58.210.124/
Thanks,
Charlie
CharlieShrem.com | *Please **encrypt messages with my PGP key
<http://charlieshrem.com/contact/>*
On Wed, May 7, 2014 at 4:25 PM, Mike Hearn <mike at plan99.net> wrote:
> I think there a few different possible ways to go here.
>
> One is to try and simplify the setup of all the components so it all gets
> installed together. That might be feasible in some quite restricted setups
> but the installation instructions for Graphite look kind of terrifying.
>
> Another is to export stats over regular TCP and make them public so
> literally anyone can listen to the stats feed for any node. Then people who
> dig stats and graphs could work on stats aggregators that give global
> network visibility independently, effectively crawling the p2p network for
> data. It'd have the advantage of having zero setup for the node operators
> and not require much in the way of resources.
>
> For what it's worth, although the environment is a bit different inside
> Google the latter approach is used. Monitoring servers locate servers of
> interest via a discovery service, connect to them and start streaming stats
> data into a database service that can then be queried later to get graphs.
>
> The stats are also run through various rules to obtain alerts about
> problematic conditions. For example, if a subset of the network splits it
> might be hard to notice that if the node operators aren't paying attention
> and Matt's fork alert/emailing code isn't set up. But if there was a site
> crawling nodes and aggregating chain heights by version, that could trigger
> an alert to people who *are* paying attention.
>
> I know from practical experience that monitoring and analysis tends to
> appeal more to certain types of people than others. So I quite like the
> "let anyone monitor" approach. However, it may not be appropriate in a P2P
> network, I did not think about it much.
>
> Obviously I'm assuming none of the stats expose privacy sensitive data.
>
>
>
> On Wed, May 7, 2014 at 10:18 PM, Wladimir <laanwj at gmail.com> wrote:
>
>> On Wed, May 7, 2014 at 9:57 PM, Jameson Lopp <jameson.lopp at gmail.com>
>> wrote:
>> > -----BEGIN PGP SIGNED MESSAGE-----
>> > Hash: SHA1
>> >
>> > I agree that it would be awesome to offer these types of stats with the
>> installer; unfortunately the route I've taken has dependencies on several
>> other other pieces of software to do all the heavy lifting of stats
>> aggregation and chart rendering. I'm assuming that you would not want to
>> build any of that processing into Bitcoin Core itself; would you be opposed
>> to packaging other software along with the installer?
>>
>> Depends on just how much stuff it is. The idea is primarily to have an
>> installer for running a (wallet-less) node as an OS background
>> service.
>>
>> Having some statistics available would be worth some extra download
>> size, otherwise it would be pretty much invisible.
>>
>> We'd already decided that we would need something like Python for the
>> stats service. Implementing things like web services in C++ is just
>> not realistic given the time constraints and the great already-written
>> code that is out there. As an optional tool it should be external, not
>> part of bitcoind itself.
>>
>> I suppose the chart rendering happens client-side? In that case the
>> web service just has to collect and provide the data, and serve static
>> html/js files.
>>
>> Wladimir
>>
>>
>> ------------------------------------------------------------------------------
>> Is your legacy SCM system holding you back? Join Perforce May 7 to find
>> out:
>>  3 signs your SCM is hindering your productivity
>>  Requirements for releasing software faster
>>  Expert tips and advice for migrating your SCM now
>> http://p.sf.net/sfu/perforce
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> Is your legacy SCM system holding you back? Join Perforce May 7 to find
> out:
>  3 signs your SCM is hindering your productivity
>  Requirements for releasing software faster
>  Expert tips and advice for migrating your SCM now
> http://p.sf.net/sfu/perforce
> _______________________________________________
> 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/20140507/8915977a/attachment.html>