Re: Bitcoin mining reward halved
On Saturday, July 9, 2016, Christopher Morrow wrote: > On Sat, Jul 9, 2016 at 3:10 PM, Jimmy Hess > wrote: > > > On Sat, Jul 9, 2016 at 2:04 PM, > > wrote: > > > Hi, > > > > Blockchain-based replacement for RPKI involving encoding of > > IP address registry registrations assigned to a Network operator's > > specified Org ID wallet, And LOAs for propagating the announcement > > of a prefix by using Colored coins automatically distributed to a > > specified ASN by > > BGP daemon on your routers? > > > > > you are on to something... something fantastic > Ok. +1.
Re: Bitcoin mining reward halved
How'd namecoin work out? .bit taking over the internet? /kc On Sat, Jul 09, 2016 at 05:39:17PM -0400, Christopher Morrow said: >On Sat, Jul 9, 2016 at 3:10 PM, Jimmy Hess wrote: > >> On Sat, Jul 9, 2016 at 2:04 PM, wrote: >> > Hi, >> >> Blockchain-based replacement for RPKI involving encoding of >> IP address registry registrations assigned to a Network operator's >> specified Org ID wallet, And LOAs for propagating the announcement >> of a prefix by using Colored coins automatically distributed to a >> specified ASN by >> BGP daemon on your routers? >> >> >you are on to something... something fantastic. -- Ken Chase - m...@sizone.org
Re: Bitcoin mining reward halved
On Sat, Jul 9, 2016 at 3:10 PM, Jimmy Hess wrote: > On Sat, Jul 9, 2016 at 2:04 PM, wrote: > > Hi, > > Blockchain-based replacement for RPKI involving encoding of > IP address registry registrations assigned to a Network operator's > specified Org ID wallet, And LOAs for propagating the announcement > of a prefix by using Colored coins automatically distributed to a > specified ASN by > BGP daemon on your routers? > > you are on to something... something fantastic.
RE: Leap Second planned for 2016
POSIX (Unix) (normal) time does not have leap seconds. Every POSIX (Unix) (normal) minute has exactly 60 seconds. Every POSIX (Unix) (normal) hour has exactly 60 minutes. Every POSIX (Unix) (normal) day has exactly 24 hours. Every POSIX (Unix) (normal) year has 365 days, unless it is a leap year, in which case it has exactly 366 days. The POSIX time is the number of seconds (or parts thereof) that has passed since midnight, 1 January 1970 GMT. The time scale is UT1. Outside of very specialized scientific applications, EVERY computer system everywhere uses POSIX time and does time/date calculations based on POSIX time (UT1). UTC time has leap seconds. This is because UTC is a "different" time-scale than the UT1 timescale on which POSIX/Unix time is based. UTC proceeds at a different "rate" from UT1 and so, from time to time, UTC time must be adjusted to keep it in sync with POSIX/Unix (normal) time. > -Original Message- > From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of > valdis.kletni...@vt.edu > Sent: Saturday, 9 July, 2016 15:12 > To: Saku Ytti > Cc: NANOG list > Subject: Re: Leap Second planned for 2016 > > On Sat, 09 Jul 2016 12:14:03 +0300, Saku Ytti said: > > > Check the implementation on your PC. This is why code is broken and > > people don't even know it's broken. You have to use monotonic time to > > measure passage of time, which is not particularly easy to do > > portable, in some languages. > > It doesn't help that the POSIX standard doesn't represent leap seconds > anyplace, so any elapsed time calculation that crosses a leap second > is guaranteed to be wrong
Re: Leap Second planned for 2016
On Sat, 09 Jul 2016 12:14:03 +0300, Saku Ytti said: > Check the implementation on your PC. This is why code is broken and > people don't even know it's broken. You have to use monotonic time to > measure passage of time, which is not particularly easy to do > portable, in some languages. It doesn't help that the POSIX standard doesn't represent leap seconds anyplace, so any elapsed time calculation that crosses a leap second is guaranteed to be wrong pgpZWOH4ajcuy.pgp Description: PGP signature
Re: Leap Second planned for 2016
On 9 July 2016 at 22:09, wrote: > well, we've gone through a few of these now...so if it was all okay before > its likely to be again... exception: any NEW code that > you are running since last time - THAT hasnt been tested ;-) In most cases the bugs are not pathological if the elapsed time is long, it may not break anything if they are 1s off. And if they measure short elapsed time, but are done infrequently, you might just not have hit the code path at the right moment. I'm sure you've had your share of difficult to track down bugs requiring very specific set complicated conditions. I give little value in black-box testing, lot of effort and very high chance of just not hitting all bug prerequisites, unit testing is much more fruitful, but alas in walled garden not possible. ++ytti
Re: Bitcoin mining reward halved
On Sat, Jul 9, 2016 at 2:04 PM, wrote: > Hi, Blockchain-based replacement for RPKI involving encoding of IP address registry registrations assigned to a Network operator's specified Org ID wallet, And LOAs for propagating the announcement of a prefix by using Colored coins automatically distributed to a specified ASN by BGP daemon on your routers? Err... >> This is pretty O/T for this list, isn't it? > > not if he's using his routers ASICs to do it! ;-) > (or maybe its related to the bitcoin network traffic volumes...but > thats too logical...) > > alan -- -JH
Re: Leap Second planned for 2016
Hi, > Leap second handling code is not well-tested and is an ultimate corner > case. There's been debate about abolishing leap seconds; with all the well, we've gone through a few of these now...so if it was all okay before its likely to be again... exception: any NEW code that you are running since last time - THAT hasnt been tested ;-) alan
Re: Bitcoin mining reward halved
Hi, > This is pretty O/T for this list, isn't it? not if he's using his routers ASICs to do it! ;-) (or maybe its related to the bitcoin network traffic volumes...but thats too logical...) alan
Re: Bitcoin mining reward halved
This is pretty O/T for this list, isn't it? On Jul 9, 2016 12:15 PM, "John Levine" wrote: > At about 16:46 UTC block 420001 showed up on the Bitcoin blockchain, > so the mining reward per block dropped from 25 to 12.5 btc. > > Depending on whom you believe, nothing will change, or most of the > miners will go offline, or something else. My blockchain client saw > 420002 was over 25 minutes after 420001 ago, and over 10,000 waiting > transactions, so perhaps the second theory is correct. > > Anyone here tracking bitcoin P2P traffic? > > R's, > John > >
Bitcoin mining reward halved
At about 16:46 UTC block 420001 showed up on the Bitcoin blockchain, so the mining reward per block dropped from 25 to 12.5 btc. Depending on whom you believe, nothing will change, or most of the miners will go offline, or something else. My blockchain client saw 420002 was over 25 minutes after 420001 ago, and over 10,000 waiting transactions, so perhaps the second theory is correct. Anyone here tracking bitcoin P2P traffic? R's, John
Re: L3 over OTN vs pure IP/MPLS
On 8/Jul/16 04:43, Manuel Marín wrote: > Dear Nanog community > > We are currently experimenting TCP degradation issues in some metro markets > where there are multiple POPs and the IP packets have to pass multiple L3 > access devices (routers) before reaching the core router. The more L3 hops > that it goes through the more degradation we see in the Internet service. > L3 routers have the capacity in terms of pps and BW and we are using just a > small percentage of that capacity but anyway the service is degraded (No > CRC/Input errors in the links). A couple of vendors are recommending using > OTN or MPLS-TP to backhaul the connections from the access to the core but > obviously deploying OTN means a considerable amount of capex. The > flexibility and simplicity of the L3 based access network is great but > given the performance issues we are experimenting I would appreciate if you > can share your experience/recommendation with either OTN or MPLS-TP. Does > it really make sense to use a OTN/Photonic layer to backhaul the L3 > connections in a metro network? Are you running your Metro-E networks on dark fibre all the way into your core, or are you leasing a lit service from another carrier for this? If the former, you should not have any issues with performance considering a well-designed network. If the latter, you are in the hands of your carrier, and you would need to qualify that they know what they are doing before you overlay your network on top of theirs. I cannot find any benefit in running your Metro-E network on dark fibre vs. OTN into the core apart from when you hit the port bandwidth limits in your Metro-E network and need to go to DWDM to upgrade that so as to keep the fibre-count down while increasing bandwidth. We run a large dark-fibre-based Metro-E network without any DWDM equipment between most rings and our core, and there is no tangible difference in performance between services delivered on those rings or services delivered upstream in the core data centres. There is also no difference in performance between the dark fibre rings vs. the DWDM rings (although, depending on your equipment vendor, some platforms could introduce quite a bit of serialization delay, but not enough to affect actual performance). Sounds like your vendors are trying to sell you boxes... Mark.
Re: Leap Second planned for 2016
On 9 July 2016 at 04:39, Patrick W. Gilmore wrote: Hey, > But time _DOES_ flow. The seconds count > 58, 59, 60, 00, 01, … > If you can’t keep up, that’s not UTC’s fault. Check the implementation on your PC. This is why code is broken and people don't even know it's broken. You have to use monotonic time to measure passage of time, which is not particularly easy to do portable, in some languages. > As for stopping the leap seconds, talk to the planet Earth. It’s the one who > will not conveniently rotate properly. Either that, or run REEALLY Fast > in that -> direction every once in a while. :-) In practice this does not appear to be significant problem. Several thousand years must pass until clocks have shifted one hour, and we have experience on shifting clocks one hour within a year, so I'm sure we can tolerate slippage caused by not having leaps. I'm holding my thumbs up for 2023 and sanity prevailing. -- ++ytti
Re: Leap Second planned for 2016
Chris Adams : > Leap seconds are inserted to keep the atomic clocks synced with an > arbitrary time base (that is guaranteed to vary forever). There's > nothing magic about having noon UTC meaning the Sun is directly over 0° > longitude; if we didn't insert leap seconds, it would have drifted > slightly, but so what? Here is "so what". From my blog, earlier this year: "In defense of calendrical irregularity" I’ve been getting deeper into timekeeping and calendar-related software the last few years. Besides my work on GPSD, I’m now the tech lead of NTPsec. Accordingly, I have learned a great deal about time mensuration and the many odd problems that beset calendricists. I could tell you more about the flakiness of timezones, leap seconds, and the error budget of UTC than you probably want to know. Paradoxically, I find that studying the glitches in the system (some of which are quite maddening from a software engineer’s point of view) has left me more opposed to efforts to simplify them out of existence. I am against, as a major example, the efforts to abolish leap seconds. My reason is that studying this mess has made me more aware than I used to be of the actual function of civil timekeeping. It is to allow humans to have consistent and useful intuitions about how clock time relates to the solar day, and in particular to how human circadian rhythms are entrained by the solar day. Secondarily to maintain knowledge of how human biological rhythms connect to the seasonal round (a weaker effect but not a trivial one). Yes, in theory we could abolish calendars and timestamp everything by atomic-clock kiloseconds since an epoch. And if there ever comes a day when we all live in completely controlled environments like space habs or dome colonies that might actually work for us. Until then, the trouble with that sort of computer-optimized timestamp is that while it tells us what time it is, it doesn’t tell us what *kind* of time it is – how the time relates to human living. Day? Night? Season? Those sideband meanings are an important component of how humans use and interpret time references. Yes, I know January in Australia doesn’t mean the same thing as January in the U.S. – the point is that people in both places have stable intuitions about what the weather will be like then, what sorts of holidays will be celebrated, what kind of mood is prevalent. I judge that all the crap I go though reconciling scientific absolute time to human-centered solar time is worth it. Because when all is said and done, clocks and calendars are human instruments to serve human needs. We should be glad when they add texture and meaning to human life, and beware lest in our attempts to make software easier to write we inadvertently bulldoze away entire structures of delicate meaning. UPDATE: There is one context, however, in which I would cheerfully junk timezones. I think timestamps on things like file modifications and version-control commits should always be kept, and represented, in UTC, and I’m a big fan of RFC3339 format as the way to do that. The reason I say this is that these times almost never have a human-body-clock meaning, while on the other hand it is often useful to be able to compare them unambiguously across timezones. Their usage pattern is more like scientific than civil time. -- http://www.catb.org/~esr/";>Eric S. Raymond
