Forgot your password?
typodupeerror

Comment: Shamir Secret Sharing (Score 1) 381

by blach (#45904321) Attached to: Ask Slashdot: How To Protect Your Passwords From Amnesia?

This (the parent comment) bears repeating and expounding-upon.

Use Shamir's Secret Sharing you can arbitrarily choose the number pieces into which your secret will be broken (N) as well as the minimum number required to reconstitute the secret (M). It is referred to as "M of N."

For example, you could perform the 3 of 5 operation on your master password, distribute 1 piece to your best friend, 1 piece to your lawyer, 1 piece to your sibling, and keep two pieces for yourself in your home safe. Or distribute those two to other trusted persons. Whatever. Any combination of THREE of the five pieces will reconstitute your master password.

You can build in any level of redundancy you wish.

Comment: Re:Weekly/Monthly Salary (Score 0) 1103

by blach (#44156319) Attached to: Employers Switching From Payroll Checks To Prepaid Cards With Fees
I feel like basic financial management (what is a bank account; why should you save?) is the kind of thing that should be taught in primary and/or secondary schooling. Certainly for a large percentage of people it would be far more useful than (for example) certain mathematics or science classes, and far more beneficial to society as a whole -- and I say this as a person with a degree in mathematics.

Comment: Re:Oddly... I have a clue about this stuff lately (Score 1) 138

by blach (#44148769) Attached to: The DNA Data Deluge
If I could add a little bit about CNV -- yes, it can be detected from ExomeSeq and yes you can infer it, to some extent from sequencing depth, given adequate depth. BUT there are a few caveats. First, exomeSeq is typically amplicon based and not all amplicons have uniform amplification. Second, while you could make gross calls (heterozygous deletion, 3x or greater amplification) from Exome data alone, it would be hard to say that one area had 1.6x (for example) amplification without really massive sequencing depth. To make better CNV calls with exome data it is useful to have control DNA (as in the arrayCGH technique which has heretofore been the standard for detection of CNV) sequenced under exact same conditions at exact same time in order to do a better genome-wide* circular binary segmentation procedure.

* actually you would probably only want to simulate probes at the center of each exon target region in your whole-exome sequencing kit; this should be available from the kit vendor

Best of luck to you and your family.

Comment: Re:I don't want them making money out of my earnin (Score 1) 430

by blach (#40310019) Attached to: With Euro Zone Problems, Bitcoin Experiencing Boost In Legitimacy

...As has been stated before, it's a question of backing. Government-issued currencies are backed up by a promise from the government that they will accept them in payment for taxes and, often, by a legal requirement for merchants to accept them within the relevant country's borders. This guarantees that you will be able to exchange them for goods or services in the future, for as long as the government survives, although it does not guarantee that they will retain the same value.

(emphasis mine)

I wanted to make the very important point that promises can be and are broken.

I would highly recommend the short book Fiat Money Inflation in France by Andrew D. White, the founder and first president of Cornell University. It can be read online for free at: https://mises.org/store/Fiat-Money-Inflation-in-France-P435C1.aspx but I would encourage you to purchase a print copy (for cheap) here: https://mises.org/store/Fiat-Money-Inflation-in-France-P435C1.aspx.

Regarding the assertion that governments and merchants will accept a currency as long as the government survives, I am glad you added the caveat about no guarantee of value, for that is important, but more importantly governments have and most probably will in the future completely change currencies. You may or may not have an opportunity to exchange.

Comment: I tried to help this project 3 months ago :-| (Score 1) 179

by blach (#33657954) Attached to: Codec2 — an Open Source, Low-Bandwidth Voice Codec

I wrote to Bruce Perens and David Rowe the following email early July 2010. David Rowe responded, understandably, that his primary area of interest and knowledge is really just in the voice codec itself, and he had no specific comment regarding my proposals for modulation and FEC. Bruce Perens never replied to me, which was a disappointment. Perhaps my note never made it past his spam filter.

So, since there is active discussion going on here (with many folks who know much more about signal engineering than me), I am posting the email its entirety, and I sincerely invite comment about my proposals regarding modulation and FEC (particularly to point out anything which is factually incorrect).

Perhaps Bruce would be willing to comment as well.

====== email below ======

Gentlemen,

I am a newly licensed amateur radio operator, and have read with interest in the past weeks about different modes of digital radio. Having read about D-Star, I recognized the need for an open alternative to AMBE, and then was pleasantly surprised to have run across both of your codec2 project sites.

I wanted to share some of my thoughts regarding this project, especially with respect to the longer-term design goals.

-----
VOICE CODEC

I read an old post by David, either on his blog or in a list serve archive, where he asked whether it would be better to (1) release an alpha version of the codec NOW and risk turning people off with poor audio quality or (2) wait for better audio quality before the first release but risk people losing interest and drifting away. I favor early release for the reason that there would be more time for (parallel) development of other softwares around the codec, time to flesh out bugs in the protocol, on-air tests could be conducted, etc. Hardware could even be started in the meantime; the final codec version could later be loaded onto an FPGA.

-----

PROTOCOL DESIGN

Although I certainly see the allure of keeping the existing modem and plugging in a daughterboard to swap AMBE to codec2 (ie, modding existing D*Star HT or mobile), I suggest that a redesign of the protocol altogether may be far more beneficial in the long run.

Presently, as I understand it, D-Star DV allocates its 4800b/s as follows:
+ 2400 AMBE voice
+ 1200 of 2/3 FEC ( actually the voice + FEC are included together in a single frame)
+ 1200 data (no FEC!)
(obviously header/overhead/sync is a part of the 1200 data)
= GMSK modulated it occupies ca 6.25kHz.

I would like to see it done this way instead:
+ header with id, routing?, and _specified division of voice and data_
+ (3200 voice) OR (3200 data) OR ( 2400 voice + 1200 data)
+ 1600 FEC for all of above
= QPSK modulated it could occupy as little as 3kHz bandwidth (at eff 1.6 ; theoretical max for QPSK is 2 = 2.4kHz bw).

-----

OTHER THOUGHTS

1. If we used QPSK modulation with spectral efficiency of 1.6, we could increase the total data rate to 9600bps while maintaing the same occupied bandwidth of ca. 6kHz.

2. My proposed header specifies that the voice rate is [3200] or [2400] (or, if we bump the total rate to 9600, we could have a maximum of 6400 bps voice data rate with 2/3 FEC) ; the receiver would implement the correct decoding. I don't know how tolerant the current algorithms are of changing the codec bitrate midstream (Speex has VBR though, so I suppose it could work).

3. No. 2, above, is important as data could be streamed intermittently, irrespective of whether or not a voice transmission is taking place.

4. With good filters, 9600 bps could still be GMSK modulated and occupy a standard FM channel width of 12.5kHz but I suppose this is dodgy.

5. I am not as familiar with the tradeoffs of GMSK v. QPSK (power efficiency, SNR, complexity?) and I'm sure there is a good reason GMSK was chosen for D-Star.

6. FEC.
    a. D-Star includes no FEC on the header or data frames! The FEC is an integral part of AMBE.
    b. Instead of building FEC into the voice codec, I favor including FEC for the entire packet (to include the voice AND data frame), in contrast to D-Star.
    c. Bruce's site mentions that Turbocodes will be going off patent in a few years, and that France Telecom is happy to license to radio amateurs gratis in the meantime. Although I am not a signals expert, my cursory investigation indicates that LDPC (low density parity check) codes may offer several advantages.
          1. Completely unencumbered. Invented in a 1960 Sc.D thesis by Robert Gallager
          2. More efficient then Turbocodes on slow or low-complexity hardware.
          3. Parallelises well

-----

I recognize this was a long and perhaps poorly-structured ramble, but I am very interested to hear what you both have to say. If you can think of a mailing list or message forum where I might post this to solicit other feedback, please let me know.

Warm regards,
name & call sign redacted
city redacted

REFERENCES
1. Bruce Perens' codec2 vision. http://www.codec2.org/
2. David Rowe's codec2 project page. http://www.rowetel.com/ucasterisk/codec2.html
3. D-Star Protocol Description. http://www.aprs-is.net/downloads/DStar/DSTARUncovered.pdf
4. Low Density Parity Check (LDPC) codes. http://www.ldpc-codes.com/

Assembly language experience is [important] for the maturity and understanding of how computers work that it provides. -- D. Gries

Working...