Bitcoin Forum
February 23, 2018, 09:08:56 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: [1] 2 3 »
1  Economy / Securities / [ActiveMining] Post your censored concerns from the moderated ActiveMining threa on: March 17, 2014, 05:56:45 PM
zumzero and his goons will censor any legitimate concerns within their thread.

Here is an archive which will include any deleted posts: https://bitcointa.lk/threads/activemining-official-shareholder-discussion-thread-moderated.259468/page-66

I am an investor in ActiveMining from the very beginning.  

I am not a troll spreading FUD.

If you have been censored and want your voice heard feel free to post here along with any posts of yours that were deleted/censored.

Most recent of mine:


Quote
Vince's post says it all guys.  Things are going to change very soon.  Smiley

BRO! I cannot take you seriously anymore. you are delightfully deliriously delusional.

+1  After him saying bitcoin will be $3k+ by september I know this guy is either a puppet or taking a high dose of happy/dreamland pills.

In fact, let's put our money where our mouths are.  Let's set up a bitbet.us bet for say a modest 0.1 BTC that the price of Bitcoin (Bitstamp) will NOT reach $3000 by September 1 2014?

It doesn't really matter what side of the fence anyone is on at this stage.

One undeniable truth exists for us all, be we trolls or fanboys, and that is;  this thing is coming to a head next week whether we like it or not.

GOOD LUCK

edit:  minerpart, you should try to keep up with the news in Bitcoinland as the price will see $3000 and not $300, and that will happen before September.  My guess is the next run up will start within the month.


This company is a fucking joke and I already have 3 people willing to pursue legal actions once this deadline counts down.

Ken get your fucking shit together.

Timer removed. End time: 2014-04-01+00:00:00UTC  

Until we get some sufficient evidence, information, shares, etc else I will be filing a complaint here once above timer ends.

I have made initial contact with this law firm as well in preparation.  If this "news" in "two weeks" is the same old words of little value then I will proceed further.

If anyone would like to join me feel free to PM me at the appropriate time (2014-04-01)

Your move Ken.


// I expect this to get censored.

There is an obvious divide between shareholders at the moment and understandably we fall into two very different camps.  Believe me when I say we'll all be on the same team again, soon.  Smiley

This talk of pump and dump is just wrong. The success of this company is what will boost the share price to an ATH.  It's a great time to be an ActM shareholder!


Yea, the ATH prices were a result of news of FAILED projects.

If you have insider information why don't you share it and quit spewing your happy go lucky bullshit!?
2  Economy / Services / Anyone Use Revel Systems POS? on: March 07, 2014, 11:59:34 PM
I am about to open up a brick and mortar shop and need a POS system which also tracks inventory.  I know there are many options out there such as square/shopkeep etc but I came across Revel and it seems like it combines bitcoin as well.  Initially I had planned on using Square and have a second tablet with Coinbase on it but was wondering if anyone has any experience with this all in one system?

http://techcrunch.com/2014/02/11/revel-systems-adds-native-bitcoin-transactions-to-its-pos-offering/

Thanks!
3  Bitcoin / Bitcoin Discussion / Welcome, Apple. Seriously. on: February 06, 2014, 08:28:49 AM



EDIT:

Side by side image thanks to bitcoiner49er



Perhaps we should come up with an official hashtag for social networks?  #WelcomeAppleBTC
4  Economy / Gambling / Most active sports betting site? on: November 28, 2013, 07:36:24 AM
I used to use anonibet a year or so ago but it seems like it has lost users.  What is currently the most populated sports betting site?  I'd like to bet on the NFL games for turkey day!
5  Economy / Computer hardware / [WTS]G.Skill 2x8GB DDR3 |OCZ 3x2GB Tripple Channel DDR3 |2TB External HDD |*NEW* on: November 14, 2013, 03:16:36 AM
All pricing shall be done via BitcoinAverage  (does anyone know how to make those cool adjusting icons with bitcoinaverage?)

G.SKILL Value Series 8GB (2 x 4GB) 240-Pin DDR3 SDRAM DDR3 1333 (PC3 10666) Desktop Memory Model F3-10666CL9D-8GBNT  
Newegg: $79.99
CONDITION: new
PRICE: x1 $65 shipped (USA)
          x2 $120 shipped (USA)



  • DDR3 1333 (PC3 10666)
  • Timing 9-9-9-24
  • Cas Latency 9
  • Voltage 1.5V

OCZ Gold 6GB (3 x 2GB) 240-Pin DDR3 SDRAM DDR3 1600 (PC3 12800) Low Voltage Desktop Memory Model OCZ3G1600LV6GK
Memory4Less: $481.30  <--- WTF?  I see these going for ~$80 new on eBay
CONDITION: near mint - ran speed tests for 12 hours for reviewing on Toms Hardware
PRICE: $55 shipped (USA)



  • DDR3 1600 (PC3 12800)
  • Timing 8-8-8-24
  • Cas Latency 6
  • Voltage 1.65V

Hitachi GST XL Desk 2TB USB 2.0 External Hard Drive
eBay: $199
CONDITION: New, in shrink-wrap
PRICE: $70 shipped (USA)



  • Smooth, Textured Body for Solid Good Looks
  • 3.5 inch External Hard Disk Drive
  • Speedy USB 2.0 Cable Included
  • Power Adapter Included
  • Hitachi Local Backup
6  Bitcoin / Bitcoin Technical Support / How to use lock_time function on a paper wallet? on: November 11, 2013, 02:06:21 AM
I would like to create paper wallet for all my young siblings.  I will be putting BTC5 on each wallet.  However, I do not want them to be able to spend it until they are 21.

Is there any documentation on how to create these transactions and better yet how to apply them to a paper wallet?

The wiki is VERY lacking: https://en.bitcoin.it/wiki/NLockTime
7  Economy / Goods / [SELLING] Electronic Cigarette E-Cig Juice and Kits on: October 26, 2013, 06:20:15 AM
A friend of mine has a B&M e-cig shop.  I have been trying to convince him to accept bitcoin but will not budge, won't even let me just add the option to his site.  

So I decided to do a test run and show him if there is demand or not - he agreed he would allow me to implement it to his website if some interest was shown.  

I have created a Coinbase merchant account and will list some of his popular items here (creating these coinbase pages for each individual item is a PITA!).

I will be making no profit.  In fact, he will see a larger profit due to the lack of Credit Card Fees!

You can view his site here:  http://indyecigs.com/  

If you see anything on the site not listed here just let me know.  He also has many more kits that range from simple to advanced not listed on the site.  

If you are looking for anything in particular not listed on his site you can ask here or email him directly @ info@indyecigs.com - Mention Bitcoin!

All shipping (US ONLY) is a flat rate $5 and has been included.  International orders contact me first.

These products are worlds apart from the typical ones you find at a gas station.  I am happy to say I am 2 years clean from a pack a day habit thanks to e-cigs!  If you or a loved one is trying to quit, give these a serious thought!

General thumb of rule regarding nicotine strengths:
12 mg - light smokers
18 mg - pack a day
24 mg - 2+ packs a day

~2ml of e-juice equates to ~one pack of cigarettes

E-JUICE

Nicquid Apple

NicQuid Apple is a warm fresh and sweet red apple. Think apple orchard in Vermont!
30ml 12mg|30ml 18mg|30ml 24mg
20ml 12mg|20ml 18mg|20ml 24mg

Nicquid Strawbery Fuzz *My personal favourite

The perfect marriage of ripe juicy strawberries, peaches and awesomeness can be found in NicQuid Strawberry fuzz! It is a tornado for the senses and sure not to disappoint.
30ml 12mg|30ml 18mg|30ml 24mg
20ml 12mg|20ml 18mg|20ml 24mg

Midnight Express

NicQuid Midnight Express is exactly what you have been searching for! A REALISTIC and DELICIOUS TOBACCO flavor! A full bodied tobacco experience that will be the closest to the real thing you have tried! The nuttiness at the start is the appetizer, the smoke is the entree.
30ml 12mg|30ml 18mg|30ml 24mg
20ml 12mg|20ml 18mg|20ml 24mg

House Blend Fire Cured Virginia Tobacco

This is a hit for the tobacco lover.  Very smooth.
30ml 12mg|30ml 18mg|30ml 24mg
20ml 12mg|20ml 18mg|20ml 24mg


STARTER KITS

EVOD Starter Kit

This fantastic-looking kit is perfect for new or experienced vapers.

Add some juice, and this kit includes everything you will need to vape with great style, performance, and Kanger quality.
The batteries and tanks are made for each other, match perfectly, and work great together.

The Evod tanks are bottom coil design, which ensures that your wicks remain saturated with juice. It is easy to refill and performs great.  
They have replaceable heads, so you can use the tank indefinitely and replace only the heads. The Evod batteries are top of the line ego batteries, and they have a unique feature.
They have a constant voltage output of 3.7 volts. They will hit hard throughout the discharge cycle of the battery.
These batteries will provide you with the same great power from the start of your day until the very end.

Kit includes:

    2 Evod 1000 mah batteries
    2 Evod Heads
    3 extra bottom coil replacement heads
    1 ego USB charger
    1 USB wall adapter

Kit +Nicquid Apple 10ml 12mg
Kit +Nicquid Strawbery Fuzz 10ml 12mg
Kit +Midnight Express 10ml 12mg
Kit +House Blend Fire Cured Virginia Tobacco 10ml 12mg





8  Economy / Services / [HIRING] web dev w/ experience of reddit source code and the bitcointip bot on: October 26, 2013, 03:16:04 AM
Looking for someone who would be able to use reddits source code and familiar with the inner workings of the bitcointip bot.  

Best form of contact is on #bitcoin nick = chsados or a PM
9  Bitcoin / Bitcoin Discussion / The One True God: Satoshi Nakamoto on: October 22, 2013, 04:06:40 AM


The First Day
On the first day, The One True God Satoshi said, “Let there be Light” -- and published his White Paper.

The Second Day
On the second day, The One True God Satoshi made the first Bitcoin client, and called it Bitcoin v0.1.

The Third Day
“The Times 03/Jan/2009 Chancellor on brink of second bailout for banks” -- and there was Genesis.
At His command the world was freed from their shackles to the banking system.

The Fourth Day
On the fourth day The One True God Satoshi registered The Bitcoin Project at SourceForge.net.
At His further command, the people of the world could now unite in furthering his Holy Noble Vision.

The Fifth Day
On the fifth day The One True God Satoshi commanded the first published exchange rate of $1 = 1,309.03 BTC (and theymos thought NLS was overcharging)

The Sixth Day
One the sixth day, man was hungry, and Laszlo agrees upon paying 10,000 BTC for ~$25 worth of pizza courtesy of jercos

The Seventh Day
By the seventh day, everything was created and put into shape and order. And The One True God Satoshi rested on the seventh day and He said, “I’ve moved on to other things. It’s in good hands with Gavin and everyone.”
10  Bitcoin / Development & Technical Discussion / Bruce Schneier: Insecurities in the Linux /dev/random on: October 14, 2013, 09:03:06 PM
Does this effect any bitcoin address created from a wallet on Linux?

Insecurities in the Linux /dev/random


New paper: "Security Analysis of Pseudo-Random Number Generators with Input: /dev/random is not Robust, by Yevgeniy Dodis, David Pointcheval, Sylvain Ruhault, Damien Vergnaud, and Daniel Wichs.

    Abstract: A pseudo-random number generator (PRNG) is a deterministic algorithm that produces numbers whose distribution is indistinguishable from uniform. A formal security model for PRNGs with input was proposed in 2005 by Barak and Halevi (BH). This model involves an internal state that is refreshed with a (potentially biased) external random source, and a cryptographic function that outputs random numbers from the continually internal state. In this work we extend the BH model to also include a new security property capturing how it should accumulate the entropy of the input data into the internal state after state compromise. This property states that a good PRNG should be able to eventually recover from compromise even if the entropy is injected into the system at a very slow pace, and expresses the real-life expected behavior of existing PRNG designs. Unfortunately, we show that neither the model nor the specific PRNG construction proposed by Barak and Halevi meet this new property, despite meeting a weaker robustness notion introduced by BH. From a practical side, we also give a precise assessment of the security of the two Linux PRNGs, /dev/random and /dev/urandom. In particular, we show several attacks proving that these PRNGs are not robust according to our definition, and do not accumulate entropy properly. These attacks are due to the vulnerabilities of the entropy estimator and the internal mixing function of the Linux PRNGs. These attacks against the Linux PRNG show that it does not satisfy the "robustness" notion of security, but it remains unclear if these attacks lead to actual exploitable vulnerabilities in practice. Finally, we propose a simple and very efficient PRNG construction that is provably robust in our new and stronger adversarial model. We present benchmarks between this construction and the Linux PRNG that show that this construction is on average more efficient when recovering from a compromised internal state and when generating cryptographic keys. We therefore recommend to use this construction whenever a PRNG with input is used for cryptography.
11  Bitcoin / Project Development / SQRL: revolutionizes web site login and authentication on: October 13, 2013, 09:33:08 PM
Have you guys looked into this proposal of using QR codes for secure and anonymous logins?  This was theorized by Steve Gibson and the original white paper can be found here

A short video describing SQRL can be viewed here: http://youtu.be/ZrQboo3pA10

This seems really interesting and I think a bitcoin address could be used as a user's master key.

A user wishing to log into a website will be prompted with the following:


Wishing to login to an online service where an “SQRL” code appears nearby:
  • The user launches their smartphone's SQRL app, and lets it see the QR code.
    (Or a smartphone / tablet user taps it.  Or a laptop / desktop user clicks on it.)
  • For verification, the SQRL app displays the domain name contained in the SQRL code.
  • After verifying the domain, the user permits the SQRL app to authenticate their identity.
  • Leaving the login information blank, the user clicks the “Log in” button... and is logged in.
    (A bit of page automation could even eliminate the need to click the “Log in” button.)

Even though it is THAT simple, it is FAR
more secure than any other login solution.
(We'll define exactly what “far more secure” means, below.)

What happened behind the scenes?
  • The QR code presented near the login prompt contains the URL of the authentication service for the site. The URL includes a securely generated long random number so that every presentation of the login page displays a different QR code. (In crypto circles this long random number is known as a “nonce.”)
  • The smartphone's SQRL authentication app cryptographically hashes the domain name of the site keyed by the user's master key to produce a site-specific public key pair.
  • The app cryptographically signs the entire URL contained in the QR code using the site-specific private key. Since the URL includes a secure long random number (the nonce), the signature is unique for that site and QR code.
  • The app issues a secure HTTPS POST query to the QR code's URL, which is the authentication service for the site. The POST provides the site-specific public key and the matching cryptographic signature of the QR code's URL.
  • The authenticating web site receives and acknowledges the POST query by returning a standard HTTP “200 OK” with no other content. The SQRL app acknowledges the successful submission of the user-signed QR code.
  • The authenticating site has the URL containing the nonce which came back from the login page via the user's smartphone. It also has a cryptographic signature of that URL, and the user's site-specific public key. It uses the public key to verify that the signature is valid for the URL. This confirms that the user who produced the signature used the private key corresponding to the public key. After verifying the signature, the authenticating site recognizes the now-authenticated user by their site-specific public key.


This simple and straightforward SQRL protocol
yields a surprising array of features and benefits:

Anonymous Identification & Authentication:
  • SQRL ID:  Visitors to a website are uniquely identified by an absolutely anonymous SQRL ID. Their “SQRL ID” is simply their public key, described above, a 256-bit number. The same visitor always presents the same ID every time they visit the same site. But no two visitors will ever have the same ID. Thus a single website can uniquely and anonymously identify every one of their visitors.
  • SQRL IDs are both user AND site specific: Although the same user always presents the same ID to the same site, they present an entirely different ID to every other site they visit. There is NO WAY TO ASSOCIATE the SQRL ID presented to one site with those presented to any other sites. In other words, there is absolutely no cross-site coupling of identity. Users are free to use their SQRL identity anywhere and everywhere because every site receives its own unique SQRL ID.
  • No annoying account creation: Suppose you wish to simply comment on a blog posting. Rather than going through the annoying process of “creating an account” to uniquely identify yourself to a new website (which such websites know causes them to lose valuable feedback traffic), you can login using your SQRL identity. If the site hasn't encountered your SQRL ID before, it might prompt you for a “handle name” to use for your postings. But either way, you immediately have an absolutely secure and unique identity on that system where no one can possibly impersonate you, and any time you ever return, you will be immediately and uniquely known. No account, no usernames or passwords. Nothing to remember or to forget. Your SQRL identity eliminates all of that.

Anonymous Identification & Authentication:
  • Identification vs Authentication:  SQRL-enabled websites have only your unique SQRL ID to disclose, and it is useful only to that single site since every users SQRL ID is automatically unique for every site they visit. There need not be any username or password for sites to have compromised, lost or stolen. Your SQRL ID does not authenticate your identity, it only identifies you to that single website. Authentication requires the SQRL smartphone app to cryptographically sign a long random number and return it with your SQRL ID (your public key). Thus, even if a hacker were to obtain your stored SQRL ID, it is useless for impersonating you—even to that one site—because the private key required to create the signature never leaves your smartphone.
  • No keyboard interaction:  Imagine that you want to login to a computer at an unsafe location such as a library or a hotel. With SQRL, your login occurs without entering any personal credential information into the computer. You provide no username or password that might be captured by a keystroke logger or resident malware. The website issues an “SQRL authentication challenge” in the form of a unique SQRL graphic code. If you have an SQRL smartphone app, it takes up the challenge and sends the website a unique challenge response that can only have come from you. The website then logs you in when you click “Log in” under the still-empty login form. From the standpoint of that computer—and anything it might contain that's attempting to spy on you—you are magically logged in without your credentials ever appearing or passing through. Your smartphone's SQRL application saw the site's SQRL code, instantly identified you to the site, and provided cryptographic proof that the person who just clicked the “Log in” button . . . is you.
  • No “shared secrets” with websites:  Six-digit time-based authenticators are based upon a cryptographic secret known only (we hope) to your smartphone and the authenticating website. This allows the website and your phone to agree upon which six-digits will be shown at any time. While this has the benefit of always changing, it repeats the username and password problem of needing to always be kept secret . . . which websites continuously demonstrate is beyond them. (And remember, the employees of those websites do have access to your credentials.) Also like passwords, because they are not truly secure, you must employ a separate and unique authentication sequence for every website you use. If this were to become popular and widespread, you would soon be scrolling through hundreds of six-digit numbers to find the right one.
  • Out-of-band authentication:  In the context of an untrusted computer, we mentioned above how website visitors were almost magically logged in without touching the computer's keyboard. This is one aspect of an important security principle known as “out of band.” The principle is that it is generally more secure not to send all aspects of a secure communication through a single channel because the security of that channel may be compromised. Entering your username, password, and one-time password all through the same keyboard is worrisome “all in band” authentication. Difficult though it might be to compromise the security of any single channel, it is vastly more difficult to simultaneously compromise two very different forms of communication. Since SQRL uses a smartphone's connection to the internet, perhaps even a cellular carrier, it avoids reusing most or all of the local computer's channel. Authentication often occurs completely “out of band”, and thus invisible to any intruder monitoring the computer's communications.
  • No third-party involvement:  In this era of pervasive government surveillance and US NSA coercion, who is going to trust any third-party with their identity? Other identity systems and solutions attempt to “federate” trust by creating a role for themselves as a third party with whom you establish a separate trust relationship. Then the authenticating website asks that third party to verify your identity on your behalf. It would be one thing if there were no alternative. But this page, and the pages that follow, demonstrate that secure and practical anonymous identification can use an entirely first-party protocol while delivering extreme ease of use.

Secure and practical anonymous identity
authentication can use a first-party protocol
while delivering extreme ease of use.

The LACK of third-party involvement
  • The use of a third-party “middleman” transfers much of the responsibility for the management of your online identity to an external facility. In an era of secret national security letters compelling the disclosure of whatever the government desires, that's a serious liability (as mentioned above), but it can also be a significant benefit: If your smartphone escapes from your control, you need only tell the third-party to cancel the phone's authentication authority and you're immediately protected from malicious use of your smartphone's identity assertion.
  • This SQRL system concentrates ALL authentication authority into the smartphone. The benefit is that no one else has the keys to your online identity.  No one.  But the liability is that YOU are then absolutely responsible for maintaining the security of your online identity.
Ultimately, someone has to be responsible for your identity.
Should it be you, or someone else?

This is a serious issue that needed to be addressed.  Our solution is to provide the user with a conceptually simple set of tools to dramatically ease the burden of assuming and managing this responsibility. As subsequent pages detail, the system provides extensive cloning, backup, local password protection and reset capability.

Hold on a second . . .  We send the website a signed bunch of gibberish?  That's it?
Yes.  And that's exactly the point.  SQRL provides absolutely anonymous identity authentication (IA). Users are identified only by a random “opaque token” and each unique combination of user and website creates a unique identity token. Thus, every user presents a unique identity to every website they visit. It is up to the user and the website to then (optionally) bind the user's unique SQRL identity to a real-world account on the website.

For example, Amazon's account management might have an option to associate a logged in user with their Amazon SQRL identity. So Amazon would present a unique SQRL code on the account management page. The user simply snaps it with their smartphone's SQRL app and now Amazon can add their SQRL ID to their account. From now on, the user can login to Amazon anywhere with vastly improved security just that easily.

And it would probably work the other way around too: Amazon's login page would present traditional login fields and a SQRL code on the side. An existing Amazon user who is establishing their SQRL identity snaps the SQRL code with their new smartphone app and Amazon replies that it does not recognize the user. If they wish to create a new account, they may do so here, or if they are an existing user, please use traditional login one last time to associate their new SQRL identity with their existing Amazon account.

Defending against the dark forces
Why we prominently display the domain name BEFORE authenticating:  The smartphone has no way of knowing the website the user is visiting. It only receives the domain contained in the QR code displayed by that page. In the "Evil Website" attack (also discussed on the attacks page), a malicious website pretends to offer an SQRL login for itself (www.we-are-evil.com), but instead it obtains and displays a login QR code from some other domain (www.amazon.com) where an SQRL user may be known. The SQRL app always identifies and authenticates its user to the domain contained within the (human unreadable) QR code. So an unwitting user, who didn't know the domain they were authenticating to, would be logging themselves into a session initiated and controlled by the Evil Website, thus allowing the Evil Website to impersonate them.

Note that even in this instance, none of the user's login credentials ever become known to the Evil Website. The Evil Website only gets a spontaneously logged-in session (though that's clearly not a good thing!)

This risk can be easily thwarted, however, simply by having the user's smartphone first prominently display the domain name it will authenticate to only if the user first gives it permission. The user knows they are visiting “www.we-are-evil.com.” So if their phone asks for permission to login to “www.amazon.com” they just say no.

Trusting the app: Though it should go without saying, it's better to say it: Until SQRL support is moved into the underlying smartphone OS, and is then curated perhaps more carefully, users will be responsible for choosing and installing an SQRL client into their smartphones. As the SQRL system gains in popularity, it is foreseeable that malicious developers might create malicious applications to steal their users' credentials. This is not a problem that's in any way unique to SQRL. Any sort of identity or password manager needs to be carefully vetted before it is entrusted with important information. The standard advice here is to stick with the herd and go with the solution that's been most thoroughly examined, checked out, and proven.


Three Ways to Go . . . smartphone optional:
(And we solve the XKCD problem above!) Although the original inspiration for the development of this system was a smartphone scanning a QR code on a website's login page, a small addition to that model enables two more significant modes of operation: Simply make the QR code image also a clickable link to the same URL that's encoded into the QR code. This yields three ways to login:
  • Scan the code with a smartphone:  Using the model described above, a user's smartphone scans the QR code appearing on a website's login page and the user is logged into that site.
  • TAP THE CODE on a smartphone:  To login to a website ON the smartphone, when the visual SQRL code is also a URL-style link (using sqrl:// as the scheme) the SQRL app installed in the smartphone will receive that link and securely log the user into the site on the phone.
  • Click the code on a desktop or laptop screen:  To use the SQRL system on any desktop or laptop system, a desktop SQRL application would be installed and would register itself to receive sqrl:// links. (This is similar to the way an email program registers to receive mailto: links.) This allows the same solution to be used by users on their desktop that they are using on their smartphones. When any website offers an SQRL code the user just clicks on the code with their mouse cursor and the locally installed SQRL app will pop-up, prompt for their SQRL password, confirm the domain, and then log them in.

Practical Considerations:
  • Open & free, as it should be:  The component techniques and technologies employed by this solution are all well known, well tested, well understood, unencumbered by patents, and exist in the public domain. The entire system can be readily assembled from 100% open source algorithms, packages and libraries.
  • The chicken & egg problem:  There was a time before the Internet, when people asked: If there are no high-quality websites no one will use the Internet; and if no one is using the Internet no one will bother creating high-quality websites. Somehow it happened anyway. We hope and expect that SQRL login will be like that. Once we have established the required interoperability standards, people WILL create free smartphone SQRL clients—probably many. And as websites begin to offer SQRL login as a side-by-side alternative to the traditional username and password, SQRL popularity will grow. Why would anyone NOT use it when it's free, perfect, and just works? Users will want it because it immediately eliminates the most annoying aspect of the Internet. Website visitors will demand it and websites will soon see that they are losing visitors by not offering the instantaneous SQRL option. Now that we have such a terrific egg, it's difficult to see what's going to keep it from hatching, surviving, and growing.
  • NSA & NIST-free cryptography:  The recommended implementation of this system leverages several unique characteristics of well-known cryptographer Dr. Daniel J. Bernstein's (DJB) carefully designed twisted Edward's curve digital signature algorithm (EdDSA). In his extensive and complete papers (linked herein) Bernstein explains the detailed derivation and properties of his “25519” elliptic curve. Importantly, there are no mysterious constants or “magic numbers” of unknown provenance. Dan has a long and well-known history of fighting for cryptographic freedom. In 1995, while a student at the University of California, Berkeley, Dan brought a lawsuit against the United States (represented by the EFF) challenging the restrictions on the export of cryptography . . . because he wanted to publish a paper and associated source code of this “Snuffle” encryption system. The ruling in the case declared software as protected speech under the First Amendment, and national restrictions on encryption software were overturned. (He won.) Please see the Detailed Crypto Architecture page for full detail and discussion.

The following pages continue to describe this SQRL system:
12  Other / Meta / SQRL: revolutionizes web site login and authentication on: October 13, 2013, 09:31:10 PM
Have you guys looked into this proposal of using QR codes for secure and anonymous logins?  This was theorized by Steve Gibson and the original white paper can be found here

A short video describing SQRL can be viewed here: http://youtu.be/ZrQboo3pA10

This seems really interesting and I think a bitcoin address could be used as a user's master key.

A user wishing to log into a website will be prompted with the following:


Wishing to login to an online service where an “SQRL” code appears nearby:
  • The user launches their smartphone's SQRL app, and lets it see the QR code.
    (Or a smartphone / tablet user taps it.  Or a laptop / desktop user clicks on it.)
  • For verification, the SQRL app displays the domain name contained in the SQRL code.
  • After verifying the domain, the user permits the SQRL app to authenticate their identity.
  • Leaving the login information blank, the user clicks the “Log in” button... and is logged in.
    (A bit of page automation could even eliminate the need to click the “Log in” button.)

Even though it is THAT simple, it is FAR
more secure than any other login solution.
(We'll define exactly what “far more secure” means, below.)

What happened behind the scenes?
  • The QR code presented near the login prompt contains the URL of the authentication service for the site. The URL includes a securely generated long random number so that every presentation of the login page displays a different QR code. (In crypto circles this long random number is known as a “nonce.”)
  • The smartphone's SQRL authentication app cryptographically hashes the domain name of the site keyed by the user's master key to produce a site-specific public key pair.
  • The app cryptographically signs the entire URL contained in the QR code using the site-specific private key. Since the URL includes a secure long random number (the nonce), the signature is unique for that site and QR code.
  • The app issues a secure HTTPS POST query to the QR code's URL, which is the authentication service for the site. The POST provides the site-specific public key and the matching cryptographic signature of the QR code's URL.
  • The authenticating web site receives and acknowledges the POST query by returning a standard HTTP “200 OK” with no other content. The SQRL app acknowledges the successful submission of the user-signed QR code.
  • The authenticating site has the URL containing the nonce which came back from the login page via the user's smartphone. It also has a cryptographic signature of that URL, and the user's site-specific public key. It uses the public key to verify that the signature is valid for the URL. This confirms that the user who produced the signature used the private key corresponding to the public key. After verifying the signature, the authenticating site recognizes the now-authenticated user by their site-specific public key.


This simple and straightforward SQRL protocol
yields a surprising array of features and benefits:

Anonymous Identification & Authentication:
  • SQRL ID:  Visitors to a website are uniquely identified by an absolutely anonymous SQRL ID. Their “SQRL ID” is simply their public key, described above, a 256-bit number. The same visitor always presents the same ID every time they visit the same site. But no two visitors will ever have the same ID. Thus a single website can uniquely and anonymously identify every one of their visitors.
  • SQRL IDs are both user AND site specific: Although the same user always presents the same ID to the same site, they present an entirely different ID to every other site they visit. There is NO WAY TO ASSOCIATE the SQRL ID presented to one site with those presented to any other sites. In other words, there is absolutely no cross-site coupling of identity. Users are free to use their SQRL identity anywhere and everywhere because every site receives its own unique SQRL ID.
  • No annoying account creation: Suppose you wish to simply comment on a blog posting. Rather than going through the annoying process of “creating an account” to uniquely identify yourself to a new website (which such websites know causes them to lose valuable feedback traffic), you can login using your SQRL identity. If the site hasn't encountered your SQRL ID before, it might prompt you for a “handle name” to use for your postings. But either way, you immediately have an absolutely secure and unique identity on that system where no one can possibly impersonate you, and any time you ever return, you will be immediately and uniquely known. No account, no usernames or passwords. Nothing to remember or to forget. Your SQRL identity eliminates all of that.

Anonymous Identification & Authentication:
  • Identification vs Authentication:  SQRL-enabled websites have only your unique SQRL ID to disclose, and it is useful only to that single site since every users SQRL ID is automatically unique for every site they visit. There need not be any username or password for sites to have compromised, lost or stolen. Your SQRL ID does not authenticate your identity, it only identifies you to that single website. Authentication requires the SQRL smartphone app to cryptographically sign a long random number and return it with your SQRL ID (your public key). Thus, even if a hacker were to obtain your stored SQRL ID, it is useless for impersonating you—even to that one site—because the private key required to create the signature never leaves your smartphone.
  • No keyboard interaction:  Imagine that you want to login to a computer at an unsafe location such as a library or a hotel. With SQRL, your login occurs without entering any personal credential information into the computer. You provide no username or password that might be captured by a keystroke logger or resident malware. The website issues an “SQRL authentication challenge” in the form of a unique SQRL graphic code. If you have an SQRL smartphone app, it takes up the challenge and sends the website a unique challenge response that can only have come from you. The website then logs you in when you click “Log in” under the still-empty login form. From the standpoint of that computer—and anything it might contain that's attempting to spy on you—you are magically logged in without your credentials ever appearing or passing through. Your smartphone's SQRL application saw the site's SQRL code, instantly identified you to the site, and provided cryptographic proof that the person who just clicked the “Log in” button . . . is you.
  • No “shared secrets” with websites:  Six-digit time-based authenticators are based upon a cryptographic secret known only (we hope) to your smartphone and the authenticating website. This allows the website and your phone to agree upon which six-digits will be shown at any time. While this has the benefit of always changing, it repeats the username and password problem of needing to always be kept secret . . . which websites continuously demonstrate is beyond them. (And remember, the employees of those websites do have access to your credentials.) Also like passwords, because they are not truly secure, you must employ a separate and unique authentication sequence for every website you use. If this were to become popular and widespread, you would soon be scrolling through hundreds of six-digit numbers to find the right one.
  • Out-of-band authentication:  In the context of an untrusted computer, we mentioned above how website visitors were almost magically logged in without touching the computer's keyboard. This is one aspect of an important security principle known as “out of band.” The principle is that it is generally more secure not to send all aspects of a secure communication through a single channel because the security of that channel may be compromised. Entering your username, password, and one-time password all through the same keyboard is worrisome “all in band” authentication. Difficult though it might be to compromise the security of any single channel, it is vastly more difficult to simultaneously compromise two very different forms of communication. Since SQRL uses a smartphone's connection to the internet, perhaps even a cellular carrier, it avoids reusing most or all of the local computer's channel. Authentication often occurs completely “out of band”, and thus invisible to any intruder monitoring the computer's communications.
  • No third-party involvement:  In this era of pervasive government surveillance and US NSA coercion, who is going to trust any third-party with their identity? Other identity systems and solutions attempt to “federate” trust by creating a role for themselves as a third party with whom you establish a separate trust relationship. Then the authenticating website asks that third party to verify your identity on your behalf. It would be one thing if there were no alternative. But this page, and the pages that follow, demonstrate that secure and practical anonymous identification can use an entirely first-party protocol while delivering extreme ease of use.

Secure and practical anonymous identity
authentication can use a first-party protocol
while delivering extreme ease of use.

The LACK of third-party involvement
  • The use of a third-party “middleman” transfers much of the responsibility for the management of your online identity to an external facility. In an era of secret national security letters compelling the disclosure of whatever the government desires, that's a serious liability (as mentioned above), but it can also be a significant benefit: If your smartphone escapes from your control, you need only tell the third-party to cancel the phone's authentication authority and you're immediately protected from malicious use of your smartphone's identity assertion.
  • This SQRL system concentrates ALL authentication authority into the smartphone. The benefit is that no one else has the keys to your online identity.  No one.  But the liability is that YOU are then absolutely responsible for maintaining the security of your online identity.
Ultimately, someone has to be responsible for your identity.
Should it be you, or someone else?

This is a serious issue that needed to be addressed.  Our solution is to provide the user with a conceptually simple set of tools to dramatically ease the burden of assuming and managing this responsibility. As subsequent pages detail, the system provides extensive cloning, backup, local password protection and reset capability.

Hold on a second . . .  We send the website a signed bunch of gibberish?  That's it?
Yes.  And that's exactly the point.  SQRL provides absolutely anonymous identity authentication (IA). Users are identified only by a random “opaque token” and each unique combination of user and website creates a unique identity token. Thus, every user presents a unique identity to every website they visit. It is up to the user and the website to then (optionally) bind the user's unique SQRL identity to a real-world account on the website.

For example, Amazon's account management might have an option to associate a logged in user with their Amazon SQRL identity. So Amazon would present a unique SQRL code on the account management page. The user simply snaps it with their smartphone's SQRL app and now Amazon can add their SQRL ID to their account. From now on, the user can login to Amazon anywhere with vastly improved security just that easily.

And it would probably work the other way around too: Amazon's login page would present traditional login fields and a SQRL code on the side. An existing Amazon user who is establishing their SQRL identity snaps the SQRL code with their new smartphone app and Amazon replies that it does not recognize the user. If they wish to create a new account, they may do so here, or if they are an existing user, please use traditional login one last time to associate their new SQRL identity with their existing Amazon account.

Defending against the dark forces
Why we prominently display the domain name BEFORE authenticating:  The smartphone has no way of knowing the website the user is visiting. It only receives the domain contained in the QR code displayed by that page. In the "Evil Website" attack (also discussed on the attacks page), a malicious website pretends to offer an SQRL login for itself (www.we-are-evil.com), but instead it obtains and displays a login QR code from some other domain (www.amazon.com) where an SQRL user may be known. The SQRL app always identifies and authenticates its user to the domain contained within the (human unreadable) QR code. So an unwitting user, who didn't know the domain they were authenticating to, would be logging themselves into a session initiated and controlled by the Evil Website, thus allowing the Evil Website to impersonate them.

Note that even in this instance, none of the user's login credentials ever become known to the Evil Website. The Evil Website only gets a spontaneously logged-in session (though that's clearly not a good thing!)

This risk can be easily thwarted, however, simply by having the user's smartphone first prominently display the domain name it will authenticate to only if the user first gives it permission. The user knows they are visiting “www.we-are-evil.com.” So if their phone asks for permission to login to “www.amazon.com” they just say no.

Trusting the app: Though it should go without saying, it's better to say it: Until SQRL support is moved into the underlying smartphone OS, and is then curated perhaps more carefully, users will be responsible for choosing and installing an SQRL client into their smartphones. As the SQRL system gains in popularity, it is foreseeable that malicious developers might create malicious applications to steal their users' credentials. This is not a problem that's in any way unique to SQRL. Any sort of identity or password manager needs to be carefully vetted before it is entrusted with important information. The standard advice here is to stick with the herd and go with the solution that's been most thoroughly examined, checked out, and proven.


Three Ways to Go . . . smartphone optional:
(And we solve the XKCD problem above!) Although the original inspiration for the development of this system was a smartphone scanning a QR code on a website's login page, a small addition to that model enables two more significant modes of operation: Simply make the QR code image also a clickable link to the same URL that's encoded into the QR code. This yields three ways to login:
  • Scan the code with a smartphone:  Using the model described above, a user's smartphone scans the QR code appearing on a website's login page and the user is logged into that site.
  • TAP THE CODE on a smartphone:  To login to a website ON the smartphone, when the visual SQRL code is also a URL-style link (using sqrl:// as the scheme) the SQRL app installed in the smartphone will receive that link and securely log the user into the site on the phone.
  • Click the code on a desktop or laptop screen:  To use the SQRL system on any desktop or laptop system, a desktop SQRL application would be installed and would register itself to receive sqrl:// links. (This is similar to the way an email program registers to receive mailto: links.) This allows the same solution to be used by users on their desktop that they are using on their smartphones. When any website offers an SQRL code the user just clicks on the code with their mouse cursor and the locally installed SQRL app will pop-up, prompt for their SQRL password, confirm the domain, and then log them in.

Practical Considerations:
  • Open & free, as it should be:  The component techniques and technologies employed by this solution are all well known, well tested, well understood, unencumbered by patents, and exist in the public domain. The entire system can be readily assembled from 100% open source algorithms, packages and libraries.
  • The chicken & egg problem:  There was a time before the Internet, when people asked: If there are no high-quality websites no one will use the Internet; and if no one is using the Internet no one will bother creating high-quality websites. Somehow it happened anyway. We hope and expect that SQRL login will be like that. Once we have established the required interoperability standards, people WILL create free smartphone SQRL clients—probably many. And as websites begin to offer SQRL login as a side-by-side alternative to the traditional username and password, SQRL popularity will grow. Why would anyone NOT use it when it's free, perfect, and just works? Users will want it because it immediately eliminates the most annoying aspect of the Internet. Website visitors will demand it and websites will soon see that they are losing visitors by not offering the instantaneous SQRL option. Now that we have such a terrific egg, it's difficult to see what's going to keep it from hatching, surviving, and growing.
  • NSA & NIST-free cryptography:  The recommended implementation of this system leverages several unique characteristics of well-known cryptographer Dr. Daniel J. Bernstein's (DJB) carefully designed twisted Edward's curve digital signature algorithm (EdDSA). In his extensive and complete papers (linked herein) Bernstein explains the detailed derivation and properties of his “25519” elliptic curve. Importantly, there are no mysterious constants or “magic numbers” of unknown provenance. Dan has a long and well-known history of fighting for cryptographic freedom. In 1995, while a student at the University of California, Berkeley, Dan brought a lawsuit against the United States (represented by the EFF) challenging the restrictions on the export of cryptography . . . because he wanted to publish a paper and associated source code of this “Snuffle” encryption system. The ruling in the case declared software as protected speech under the First Amendment, and national restrictions on encryption software were overturned. (He won.) Please see the Detailed Crypto Architecture page for full detail and discussion.

The following pages continue to describe this SQRL system:
13  Economy / Securities / [BOUNTY] Colored Coins Development T-Shirt Fundraiser on: October 09, 2013, 12:33:13 AM
Repost from a reddit thread:

Quote
After the recent Bitfunder news it has become quite clear that central exchanges are not viable.

The whole concept of central security exchanges is counter intuitive to the bitcoin philosophy entirely.

COLORED COINS
is the answer. The closest thing to any implementation I have found is BITCOINX.

So how can those of us who are not programmers help? I propose we start a bounty campaign. Instead of just asking for donations I think a better way to gather funding for a development team would be through a tshirt sale such as TEESPRING.

All profit can go towards funding a bounty to a dev team.

Is there any interest in this? A shirt should be created that does not only cater to those interested in bitcoin denominated securities but rather bitcoin as a whole in order to garner wider support. Perhaps something related to DPR - or perhaps a very nicely designed general bitcoin shirt?

I am willing to invest $300 towards T-Shirts right now and start directly selling shirts for BTC if there is enough interest. I direly need help with a graphics designer for the design.

I did a quick run through teespring with a sample image and for a high quality shirt - selling 100 shirts @ $25 would profit $1.400.

Thoughts?

You can read more about colored coins from COINDESK

If you want to donate now to the BitcoinX team here is there DONATION PAGE

BitcoinX Dev Team: you guys frequent here?  How far along are you and how can non-programmers help?
14  Economy / Service Discussion / Anyone else having issues with blockchain.info on: August 26, 2013, 05:19:51 AM
It's not letting me search for addresses...

15  Economy / Service Discussion / [COINBASE] Feature Idea/Suggestion on: August 07, 2013, 03:58:06 AM
I love CoinBase and how it is making it really easy for not only users to buy bitcoins instantly, but also its excellent merchant features.  I was thinking about the following feature idea and wanted to see if you guys thought this would be possible or even desirable.

What if CoinBase allowed the possibility for merchants to allow people who do not know what Bitcoin is, or has zero interest in buying bitcoin in order to purchase a merchants product - to have the ability for that customer to input their banking information instead of sending bitcoin.

So instead of having a buy it now with BTC button, have a pay with CC or ACH button.  The merchant would obviously have to wait 3 or so days to get their BTC but it would allow a merchant to widen their customer base and still obtain bitcoins for their goods and services in one central location.

The obvious issues that could arise is fraud, or for some types of services not being able to issue the product until the payment has cleared, however I can see some situations where this could not be a problem.

Another way to mitigate the above issues is to force users to register with CoinBase and go through the verification process like they are already doing.

Thoughts?
16  Economy / Economics / Help me estimate bitcoins total merchant/market net worth on: August 06, 2013, 12:45:36 AM
I am trying to collect as much data as possible to get a rough idea how much money is being spent in bitcoins market place.  I am intersted in doing this as a result of many claims that Silk Road is the "driving marketplace of bitcoin" - which I don't think is particularly true.  If you have any links, or information about the below companies please share, I will keep it updated as more information comes in.  If you have any other suggestions on other bitcoin related merchants let me know.

BitPay ~$5 million/month
CoinBase ~15 million/month *February buy and sales total | *email
BitcoinStore Lifetime sales: $662,993 | $662,993/7(?) months = $94,713/month
BitMit ?
CoinGig ~$5,000/month
Avalon 8 million in chip orders? *from comments here on bitcointalk, looking for links
Butterfly Labs ?
KnC owner refuses to answer
AsicMiner ~$6,711,800 (unknown time frame) | Blade Sales Income: 29,594.75BTC + USB Sales Income: 37,524.00BTC
Satoshi Dice ?
BTCQuick ~ $320,721.23/month

The only data I can find on Silk Roads annual sales is roughly $22 Million a year, i.e. ~$1.8 million/month so BitPay alone technically processes more than Silk Road alone.

17  Economy / Digital goods / [WTS] TF2 Items on: August 02, 2013, 12:53:19 AM
Check out my inventory: http://tf2b.com/tf2/lsdmt

Submit offers here or message me on steam: extra137 <-- preferred.
18  Economy / Securities / [CLOSED] Here is your chance to get LABCOIN before it's unlocked! on: July 31, 2013, 11:37:43 PM
I'm willing to transfer 150 shares of LABCOIN to highest bidder.

Bidding starts at 0.002 / share

Let's Go!  Grin



Bid Increments 0.0001

Timer removed. End time: 2013-07-31+20:00:00 time left to give 30 minutes leeway for payment and share transfer.

I'll take BIN offers too  Cheesy
19  Bitcoin / Bitcoin Discussion / The general population is insanely ignorant about Bitcoin - and here's proof. on: July 03, 2013, 08:29:29 PM
I started a thread on a relatively small gamers development forum asking them to consider accepting bitcoin purchases for their newest game I am really excited about.

It really opened my eyes how people will fight tooth and nail to just discredit Bitcoin, and most of these thoughts seem to be because of articles they had read by authors who do not understand bitcoin at all.

If you would like to see how the 100+ responses in under an hour unfolds check here

I am not asking anyone to register and chime in about why you would purchase a game with bitcoin, but if you would like to go for it!

Favorite line of them all:
Quote
Ever dollar you put into your paypal and such actually exists. You could put that paypal money into a bank account and withdraw real legal tender, that you could then take to the treasury and exchange for the gold that its backed by if you wish.
20  Economy / Service Discussion / My Safe Paper Wallet Arrived! on: June 01, 2013, 11:33:48 PM
Mine arrived!  Nice work aantonop!  And the material is top notch. 





Pages: [1] 2 3 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!