Brother can you help a fiber?

[Cathal Garvey (Phone)]

I look forward to a world without patents, so I'm afraid all that waffle about obtaining a worldwide government-enforced-monopoly merely made me sigh a bit.

Jim Bell <jamesdbell8 at yahoo.com> wrote:
>    I don't quite know why I received the message below, but I am
>answering (including cypherpunks at cpunks.org) since it seems a good time
>to do so given the humorous connection to my isotopically-modified
>optical fiber invention.  And, I would like to make a request, indeed
>an offer.
>
>    A few weeks ago, when I re-appeared on cypherpunks.org, I pointed
>out that my patent application was recently (mid-July 2013) published
>by the US Patent and Trademark Office (USPTO).  See 
>http://www.freepatentsonline.com/WO2013101261A1.html     This is an
>invention that I thought of in December 2008, stuck in a prison cell at
>USP Tucson:  I realized that much of the index of refraction of
>ordinary silica (which is about 1.46; of that amount above an index of
>1.000) was due to the presence of Si-29 atoms.  (Si-29 is the only
>naturally-existing silicon atom with an 'electromagnetic spin', due to
>its unpaired neutron circulating in the nucleus.)  I concluded that by
>dramatically reducing the proportion of Si-29 atoms, which amount to
>about 4.67% atom/atom in ordinary silicon, it would be possible to make
>silica with a much-lower index of refraction:   Probably between 1.10
>and 1.02, but the amount is uncertain.
>    One big advantage of this fiber will be a far-higher 'velocity
>factor', approaching 0.90-0.98 of 'c', where 'c' is physicist-speak for
>the speed of light in a vacuum, compared with ordinary silicon optical
>fibers with a velocity factor of 1/1.46, or 0.685 of 'c'.  This will
>amount to a dramatically-faster signal velocity.   While not quite as
>fast as line-of-sight microwave, or neutrino-beams piercing the earth,
>it would be significant.   
>    
> Other advantages will be a
>reduction in optical loss by perhaps a factor of 10x (from perhaps 0.19
>db/km in existing fibers to 0.019 db/km), a reduction of optical
>dispersion by a similar factor of 10x, and an increase in useable
>optical bandwidth from 50 nanometers wavelength (1510-1560 nm) to 800
>nm (1000-1800 nm).  (The practical limit on fiber tends to be the
>limitation on the gain-bandwidth of EDFA's;  Erbium-Doped Fiber
>Amplifiers 
>http://en.wikipedia.org/wiki/Erbium_doped_fiber_amplifier#Erbium-doped_fiber_amplifiers
>  ).
>
>    Shortly I will begin preparing a prototype for this fiber, which
>will cost between $200-250K.  (USD).  I have received a committment for
>this amount.  However, having filed for a US Patent (specifically, a
>PCT or 'Patent Cooperation Treaty' filing), it will be necessary to
>file for many dozens more 'national-stage' patents:  The way patents
>work, around the world, is that a person must file for a patent in each
>nation around the world that he desires to have patent-protection in. 
>A national-stage patent costs about $10,000.  Generally, the reasoning
>is that an inventor should file for a patent in any country:
>1.    Where a significant amount of the invention will be made.
>2.     Where a significant amount of the invention will be used.
>    If I assume that the royalty per meter of fiber is $0.25/meter (25
>American cents per meter), it would be worth filing for a patent if the
>amount of fiber made or used is $10,000/$0.25, or 40,000 meters of
>fiber.  This would be about 1.1 kilometers of cable that has 36 fibers
>in it.  Obviously, even the smallest country would use enough fiber to
>justify obtaining a patent.
>
>    There are 148 PCT-signatory countries.   
>http://en.wikipedia.org/wiki/Patent_cooperation_treaty    I would like
>to obtain, at the very least, national-stage patents in at least 40
>nations, probably 80 nations, and possibly as much as 120 nations. 
>That would cost about $400,000, $800,000, or $1.2 million. (USD).   I
>have considered raising the money by means of a Kickstarter campaign,
>but that site is oriented to collecting donations of money:  It is
>specifically prohibited that a project proponent promise a financial
>return on such a contribution.  But I'm not looking for a handout:  I'm
>looking for a loan which will be paid back.   Perhaps that's called a
>'bond'? 
>    How would it be paid back?  Corning says that 300 billion meters of
>fiber were manufactured in about 2012.  If I get a market-share of 10%,
>that's 30 billion meters per year.  At a royalty of, say, $0.25 per
>meter of fiber, that would be $7.5 billion per year.  With even a tiny
>fraction of such a value, I could pay a huge return on a loan to
>finance these national-stage patent applications.  I see nothing wrong
>with a 3x return:   $3 returned for each dollar loaned, probably within
>1-2 years.  Does this sound interesting?
>     Jim Bell
>
>
>
>
>
>________________________________
> From: Peter Todd <pete at petertodd.org>
>To: Ittay <ittay.eyal at cornell.edu> 
>Cc: Bitcoin Dev <bitcoin-development at lists.sourceforge.net>; Gavin
>Andresen <gavin at bitcoinfoundation.org>; Emin Gün Sirer
><egs at systems.cs.cornell.edu> 
>Sent: Tuesday, November 5, 2013 11:56 AM
>Subject: Re: [Bitcoin-development] BIP proposal - patch to raise
>selfish mining threshold.
> 
>
>On Tue, Nov 05, 2013 at 12:43:15PM -0500, Ittay wrote:
>> On Tue, Nov 5, 2013 at 12:14 PM, Peter Todd <pete at petertodd.org>
>wrote:
>> 
>> > On Tue, Nov 05, 2013 at 12:05:41PM -0500, Peter Todd wrote:
>> > > On Tue, Nov 05, 2013 at 11:56:53AM -0500, Ittay wrote:
>> >
>> > Oh, and I don't want to give the wrong impression: there's no need
>to
>> > rush to get this problem fixed. Even if someone wanted to launch an
>> > attack right now, with a fair amount of
> resources, there's a lot of
>> > counter-measures based on human
> intervention that can definitely stop
>> > the attack in the short-term
>> 
>> 
>> The attack can be easily hidden. And be sure that before today,
>today,
>> and after today, very smart people are at their computer planning
>attacks
>> on Bitcoin. Exploits must be published and fixed FAST.
>
>Not this exploit.
>
>Here's a perfectly plausible worst-case scenario, that could be
>happening right now: RAND High Frequency Trading Corp (a subsidiary of
>General Evil) has a globe-spanning low-latency network of fiber,
>line-of-sight microwave, and some experimental line-of-site neutrino
>links criss-crossing the globe. They can get data to and from any point
>on this planet faster than anyone else. Of course, in addition
> to their
>spectacular network they have an immense amount of computing power, as
>well as exotic overclocked liquid nitrogen bathed CPU's that run at
>clockspeeds double what commercial
> hardware can do; in short, they have
>access to scalar performance no-one else has. Of course, they like to
>keep a healthy reserve so, 99% of all this fancy gear is constantly
>idle. Whatever, they can afford it.
>
>RAND just hired a bunch of fresh MIT graduates, the best of the best.
>Problem is the best of the best tends to make not so best mistakes, so
>RAND figures a Training Exercise is in order. Fortunately for them the
>NSA (a
>subsidiary of General Evil) slipped a rootkit into my keyboard a week
>or
>so ago - probably that time when I woke up in that farmers field with a
>*splitting* headache - and are reading what I'm typing right now.
>
>I go on to explain how an excellent training exercise for these fresh
>MIT graduates would be to implement this nifty
> attack some Cornell
>researchers came up with. It's really simple, elegant even, but to do
>it
>best what you really want is the kind of low-latency network
> a
>high-frequency-trading corporation would have. I then point out how a
>good training exercise ideally is done in a scenario where there is
>genuine risk and reward, but where the worst-case consequences are
>manageable - new hires to tend to screw up. (I then go on to explain my
>analog electronics background, and squeeze in some forced anecdote
>about
>how I blew up something worth a lot of money owned by my employers at
>some point in the distant past)
>
>Unfortunately for the operators of BTC Guild, one of these new MIT
>grads
>happens to have a: passed General Evil's psych screening with flying
>colors, and b: have spent too much time around the MIT Kidnappng Club.
>He decides it'd be easier to just kidnap the guy running BTC Guild than
>fill out the
> paperwork to borrow RAND's FPGA cluster, so he does.
>
>As expected the attack runs smoothly: with 30% of the hashing power,
>neutrino burst generator/encoders's rigged
> around the globe to fire the
>moment another pool gets a block, and the odd DoS attack for fun, they
>quickly make a mockery of the Bitcoin network, reducing every other
>miners profitability to zero in minutes. The other miners don't have a
>hope: they're blocks have to travel the long way, along the surface of
>the earth, while RAND's blocks shave off important milliseconds by
>taking the direct route.
>
>
>Of course, this doesn't go unnoticed, er, eventualy: 12 hours later the
>operators of GHash.IO, Eligius, slush, Bitminter, Eclipse and ASICMiner
>open their groggy eyes and mutter something about how that simulcast
>Tuesday party really shouldn't have had an open bar... or so much coke.
>
>They don't even notice that the team from BTC Guild
> has vanished, but
>they do notice a YouTube video of Gavin right on bitcoin.org doing his
>best Spock impression, er, I mean appealing for calm and promising that
>Top Men are
> working on the issue of empty blocks as we speak. Meanwhile
>CNN's top headline reads "IS THIS THE END OF BITCOIN?!?!"
>
>It takes another hour for the Aspirin's to finally kick in, but
>eventually get all get on IRC and start trying to resolve the issue -
>seems that whenever any of them produce a block, somehow by incredible
>coincidence someone else finds another block first. After a few rounds
>of this they're getting suspicious. (if they weren't all so hung-over
>they might have also found suspicious the fact that whenever they found
>a block they saw a sudden blue flash - Cherenkov radiation emitted when
>those neutrino's interacted with the vitreous humour in their eyeballs)
>
>It's quickly realized that "somehow" BTC Guild isn't affected...
>GHash.IO and
> Eligius, 22% and 13% of the hashing power respectively,
>decide to try a little experiment: they peer to each other and only
>each
>other through an encrypted tunnel
> and... hey, no more lucky blocks!
>slush, 7% of the hashing power is invited to the peering group next,
>followed by Bitminter, 6%, and Eclipse, 2%, and finally ASICMiner, 1%,
>for a grand total of... 51% of the hashing power!
>
>Of course, just creating blocks isn't useful for users, they need to be
>distributed too, so someone quickly writes up a "one-way firewall"
>patch
>that allows the group's blocks to propagate to the rest of the network.
>Blocks created by anyone else are ignored.
>
>It takes a few more hours, but eventually the attacker seems to run out
>of blocks, and transaction processing returns to normal, albeit a
>little
>slow. (20 min block average) Of course, soon there's a 3,000 post
>thread
>on bitcointalk complaining about the "centralized pool
> cartel", but
>somehow life goes on.
>
>The next day Gavin goes on CNN, and gives a lovely interview about how
>the past two days events show how the strength of
> the Bitcoin network is
>in the community. For balance they interview this annoying "Peter Todd"
>guy from "Keep Bitcoin Free!" who blathers on about how relying on
>altruism or something will doom the Bitcoin network in the long run.
>After the interview Gavin respectfully points out that maybe next time
>they find a so called "developer" with a ratio of bitcointalk posts to
>actual lines of code in the Bitcoin git repository better than one
>hundred to one. The producer just wishes that "Mike Hearn" guy was
>available; at least he's got a sense of fashion, sheesh!
>
>
>Anyway, I'm out of space for my little story, but yeah, the ending
>involves a group of now-rich pool operators who decide to start a large
>financial services and data networking company, oh,
> and time-travel...
>
>
>> Nevertheless, I agree  that, as you say, we must not rush it. Look at
>the
>> BIP, find if we missed anything, and let's
> discuss it.
>
>Indeed.
>
>Quite seriously, your attack is a serious long-term risk, but in the
>short term the social dynamics of Bitcoin are such that it's just not a
>show-stopping risk. At worst some miners will lose a bunch of money -
>that's something that's happened before with the March chain fork, and
>sure enough Bitcoin survived just fine.
>
>> > In addition, keep in mind
>> > that this attack is very easy to detect, so if one is actually
>launched
>> > we will know immediately and can start taking direct
>counter-measures at
>> > that time.
>> >
>> 
>> Not really. Please see the discussion section in our paper.
>
>You can hide *who* is the
> attacker - you can't hide the fact that an
>attack is happening if done on a meaningful scale.
>
>> > That Gregory Maxwell so quickly identified a flaw in this proposed
>> > solution suggests we should proceed
> carefully.
>> >
>> 
>> There is no flaw. You were just reiterating that the solution does
>not give
>> us the 51% percent security you thought you had before. We showed
>that
>> we're not getting this back, I'm afraid.
>
>That's not what we're concerned about - what we're concerned about is
>that your BIP doesn't discuss the issue, and you didn't seem to be
>aware
>of it. That suggests that the analysis is incomplete. There's no
>pressing need to rush changes, as explained above by example, so we're
>best off understanding the issue thoroughly first.
>
>There's a whole spectrum of potential solutions that haven't been
>discussed - I myself have two approaches I'm working on that may solve
>this problem in ways you
> haven't (publicly) considered. I'm sure there
>are many others out there.
>
>-- 
>'peter'[:-1]@petertodd.org
>00000000000000005144f6a7109b9f8543880a0a5f85a054ec53966bc2daa24c
>------------------------------------------------------------------------------
>November Webinars for C, C++, Fortran Developers
>Accelerate application performance with scalable programming models.
>Explore
>techniques for threading, error checking, porting, and tuning. Get the
>most 
>from the latest Intel processors and coprocessors. See abstracts and
>register
>http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development at lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 23820 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/cypherpunks/attachments/20131108/ec2843ba/attachment-0001.txt>