Are you talking about brand names or about any website a company owns? The latter could take forever. Brand names will take care of themselves, because anyone who buys up a trademarked name is a fool...they will get it from you eventually.

I am talking about a particular domain name like google.p2p or microsoft.p2p. I am not sure what you mean by could take forever?

I do think it is likely to be foolish for someone to squat a brand name, but I am afraid people will do it and it will hurt the DAC. Imagine an early auction on google.p2p. On one hand, people will be bidding up a lot because they think they can sell it for millions to Google later. On the other hand, the very fact that Google would need to pay a significant sum of money for their own established name on some obscure service means they would probably pass on it, hurting the entire DAC. This risk is priced in, and so google.p2p will probably be sold early on to someone (someone probably anonymous) for a cost that isn't too high. How is Google going to use lawsuits to take their trademarked name from an anonymous person on a decentralized system. They aren't, they would just ignore it instead, hurting the whole DAC by not having a powerful ally using the service. Instead, if we make it incredibly cheap and easy for the biggest, most popular websites to come on board with their recognized name, we significantly help our cause. Think of it as marketing.

 

KeyID - replacing usernames everywhere

What do you mean everywhere?

"SignIn with KeyID" - think google/facebook signin only MORE SECURE. OUTRAGEOUSLY SECURE if the website is a .p2p site.
* DNS delegates that act as smart oracles for other decentralized application platforms - ethereum, ripple, etc... KeyID usernames *all over crypto land*.

EVERYWHERE!


All joking around aside, I am really excited for this DAC. Could we finally say goodbye to managing website passwords and worrying about man-in-the-middle attacks? I hope so. And I'm also intrigued by KeyMail and KeyID points. Can't wait to learn more about them.

I am a little concerned with downburns. The economics of a downburn don't make sense to me, if it is what I think it is. Why would someone spend their own money downvoting someone else? Seems like it suffers from the free rider problem. I do have some ideas on how "downburns" (or more like "downvote collateral") could be made into something that interacts with a Lending DAC, effectively making KeyID points into something like a credit score. I'll probably write it about it sometime later.

I am also experiencing this bug.

And, in general this version seems less stable to me than 0.2.3. I don't know if it's the database getting corrupted from forcefully killing the program like maqifrnswa is speculating on https://github.com/BitShares/qt_wallet/issues/19, because for me the Qt wallet sometimes segfaults on startup and sometimes it does not. It's hard to reproduce the error since it appears to happen randomly.

There has been some discussion on the forums about the problem of trying to keep one's account name on all the different DACs that are going to be coming out. New DACs can snapshot the names on an older DAC they split off from (or Keyhotee founder IDs), but I think this is a really inelegant solution that doesn't actually fully addresses the problem, as I have discussed at https://bitsharestalk.org/index.php?topic=6420.msg85558#msg85558.

This is my proposal on how to deal with this issue. But first, I want to discuss how I understand names in the BitShares ecosystem. BitShares names are like email addresses (I believe bytemaster has already used the email metaphor to explain the naming system). An email address has two parts, the handle and the domain, e.g. james@example.com. The handle james is not universally unique; there can be a james@gmail.com, james@yahoo.com, etc. However, it is unique to a domain, and this is enforced by the mail server located by that domain. The mail server may have an IP address like 10.1.2.3, and a domain name like example.com pointing to that IP address. We have an analogous situation with BitShares: the mail server is now the DAC and the handle is the registered name on that particular DAC. The analogue to the IP address is the information necessary for universally identifying a particular instance of a DAC, such as the hash of the genesis block of a DAC. Regular people shouldn't have to deal with the hash or IP address. Instead, in the case of email, they use domain names. I think that the analogue of the domain name in BitShares is a local alias for a DAC that the client recognizes. For example "btsx" could be used to represent the particular BitShares X DAC that the client is configured to connect to. Meaning my BitShares X account could be referred to on my local machine by the name "arhag@btsx" for example. The same client might be configured to associate "namespaces" to the BitShares Namespaces/DNS/.p2p DAC (toast, which is the official name?) which the client could also connect to, or alternatively the client could send RPC calls to another client running on the user's machine that connects to the BitShares Namespaces network. These aliases are local to the client (not necessary universally recognized domain names, but by convention all clients might use the same names). You can think of them as manually setting hostnames (to continue the email analogy). I don't think manual hostnames are a burden in the BitShares ecosystem like they are for the web, because in the case of the web, your one browser can navigate to a web page located at any domain name, or your one email client can send an email to an email address at any domain name, but in the case of BitShares, you effectively need new software to run on your computer for every new DAC (or "domain") you want to be able to access.

So how does all of that deal with the unique name problem? To answer that I need to discuss how owner keys would be created for accounts in this system. By the way, I don't know the exact details of how the BitShares toolkit currently deterministically generates the owner key of an account from the wallet root key. I imagine it is similar to what I am going to discuss, but I am going to describe how I envision it should work. Each account created within a wallet would have a specific local index associated with it. That index (which in my system could be a string) along with the wallet root key determines the owner key of the account (something like WALLET_ROOT_KEY.hardened_child(ACCOUNT_INDEX) => ACCOUNT_OWNER_PRIVATE_KEY). The local index could by default be automatically set to an incrementing counter (increments each time a new account is created). To universally identify an account on any BitShares DAC, one only needs the public key corresponding to the private key that is generated purely from WALLET_ROOT_KEY and ACCOUNT_INDEX.

To make this more concrete, imagine a user James. James created a new wallet on BitShares X, and then created three accounts on that wallet. The first two accounts (jim and internetpseudonym) were created with default settings and then registered. This means the account jim was created with an owner key deterministically generated from WALLET_ROOT_KEY using the index 1, and internetpseudonym was generated using index 2. James then created a third account on the same wallet using the explicitly defined index "secretagent-2j29d94jd3s0" and was able to register it on the blockchain with the name agent007. If James now lost his hard drive and the only thing he backed up was WALLET_ROOT_KEY, his client would automatically be able to recover the two registered accounts jim and internetpseudonym, but it would not be able to automatically recovery his third registered account agent007 (this provides plausible deniability by the way!). James would have to remember and explicitly enter "secretagent-2j29d94jd3s0" into his client to recover the agent007 account and all of its funds.

James now downloads the client for the brand new BitShares Namespaces DAC. He of course wants to transfer over his accounts from BitShares X. So he imports the BitShares X wallet (or more precisely has the client extract the WALLET_ROOT_KEY and generated a new wallet with that key). The client could also look through all local accounts and their indices in the BitShares X wallet and use that to automatically set up the corresponding accounts in the new DAC. But if the client did not automatically import the wallet but nevertheless used the same WALLET_ROOT_KEY, it would still generate accounts on the new DAC with the same owner key as the corresponding account on the BitShares X DAC. By corresponding account I mean the account with the same index. So, if James creates a brand new default account on that wallet (so it has the default index 1) it would actually be an account with the same owner key as jim@btsx. And, if James decided to create a new account on that wallet using the explicit index "secretagent-2j29d94jd3s0" on BitShares Namespaces, it would create an account with the same owner key as agent007@btsx. If that account was registered on the BitShares Namespaces DAC under a different name, say jbond, outside parties would be able to associate the name jbond@namespaces to agent007@btsx because they have the same owner key. This is the link that can tie the different names of the same conceptual account on different DACs together.

So, lets say James wants to register the first account (index 1) on BitShares Namespaces blockchain. Unfortunately, jim is already taken. So he instead registers that account under james. Now james@namespaces is linked with jim@btsx. If Bob wants to transfer ownership of his domain name to James, but only has his BTSX account name (jim), Bob now has a way of finding out what name James uses on BitShares Namespaces without needing to talk to him. A lookup of jim on BitShares X can give the account's owner key. If there is a match for that owner key on BitShares Namespaces, then the corresponding account (james) must be the registered account that James uses. And so Bob can send the domain to james. This entire process can be automated by the clients. Bob should just be able to type jim@btsx in the to field and have his client automatically resolve who to send the domain name to in the background (or give an error if the user isn't registered on the relevant DACs).

Then, there is a final step to make all of this incredibly convenient and to, for example, be able to just give one universally unique name on a business card. We must develop a social consensus around which DAC everyone agrees to identify themselves with. My suggestion is that we use the upcoming BitShares Namespaces DAC for this purpose. I propose that by default every BitShares handle not further qualified with an @dacname should refer to the registered name on the BitShares Namespaces DAC. That means if someone wanted to send money to James in BitShares X but they only knew the BitShares X name (jim), they would have to send the money to "jim@btsx" (the @btsx would need to be explicit). If they just sent the money to "jim", it would instead be sent to jim@namespaces, who may not necessarily be James. The typical way this would be used, however, is for everyone to use the Namespaces DAC registered name within all DAC clients. So, the person sending money to James would learn that his Namespaces handle is james and would simply put "james" in the to field (although the explicit "james@namespaces" would be appropriate as well). If someone else wants to vote for James as a delegate on the Music DAC (on which James has registered the name jimmy@music), they would still put "james" in the to field of the Music DAC client (the system would automatically resolve james -> james@namespaces -> unique owner key -> jimmy@music). If this social consensus is followed, it becomes irrelevant what any of your registered names are except for the name registered on the BitShares Namespaces DAC. That name then becomes your universally unique name.

Great. It's good to know that there is a plan in place for this. I'm sure you have already thought through a lot of this, but I would like to throw in my two cents on how I would like to see this implemented.

What I am looking for is to have the option for something that goes beyond just a straightforward multisig. First, each registered account would publically register three public keys (PRIMARY_PUBLIC_KEY which I guess is equivalent to the Active Key in the current system, SECONDARY_PUBLIC_KEY, and TERTIARY_PUBLIC_KEY) and a MULTISIG_EXPIRATION_DELTA which specifies the time increment from the time of the transaction to the time when the transaction can be spent by just one of the keys. For privacy reasons users should not choose a rare MULTISIG_EXPIRATION_DELTA.

When a spender creates a transaction that sends money to a recipient, the spender takes OneTimePrivateKey and does elliptic curve point multiplication with PRIMARY_PUBLIC_KEY, SECONDARY_PUBLIC_KEY, and TERTIARY_PUBLIC_KEY, to get SECRET1, SECRET2, and SECRET3, respectively. Then, PRIMARY_PUBLIC_KEY.child(SECRET1) => PRIMARY_RECEIVE_PUBLIC_KEY, SECONDARY_PUBLIC_KEY.child(SECRET2) => SECONDARY_RECEIVE_PUBLIC_KEY, TERTIARY_PUBLIC_KEY.child(SECRET3) => TERTIARY_RECEIVE_PUBLIC_KEY. The corresponding receive addresses are added to the transaction for multisig purposes, along with MULTISIG_EXPIRATION_DELTA, and also two encrypted memos: PRIMARY_MEMO and TERTIARY_MEMO. PRIMARY_MEMO, which would be encrypted with SECRET1, would contain the same information currently put in the memo with TITAN. TERTIARY_MEMO (encrypted with SECRET3) would only contain information on which registered account was the intended recipient of the transaction.

Spending the transaction before (TIME_OF_TRANSACTION + MULTISIG_EXPIRATION_DELTA) would require a signature from either PRIMARY_RECEIVE_PRIVATE_KEY and SECONDARY_RECEIVE_PRIVATE_KEY or PRIMARY_RECEIVE_PRIVATE_KEY and TERTIARY_RECEIVE_PRIVATE_KEY. Spending the transaction after (TIME_OF_TRANSACTION + MULTISIG_EXPIRATION_DELTA) would require a signature from either PRIMARY_RECEIVE_PRIVATE_KEY or SECONDARY_RECEIVE_PRIVATE_KEY (but not TERTIARY_RECEIVE_PRIVATE_KEY).

Users would use their wallet root key to deterministically generate the primary key, randomly generate a secondary key and safely store it offline, assign TERTIARY_PUBLIC_KEY to the well known public key of a third-party validator, and set MULTISIG_EXPIRATION_DELTA to some reasonable value like 6 months. As long as they move their unspent transactions at least every 6 months (they already have to do it once a year anyway to avoid the inactivity fee), they get the security benefits described in my previous post. But there are additional benefits with this approach. The validator can also act as an observer for received funds. The validator would only have to scan the blockchain with just one key and then look in the tertiary memo to see which of their customers the funds belong to. They could then alert each customer with just the subset of relevant transaction for thin client wallet setups. The validators would not be able to see the primary memo field or who the money came from. They would only see the user's account balance as a function of time for the duration of time that the user had chosen that validator. If the user loses access to their wallet root key but is able to recover the offline SECONDARY_PRIVATE_KEY, they can still get access to all of their funds after at most 6 months; however, they won't be able to see their old transaction history. Also, if the user dies but had given a copy of SECONDARY_PRIVATE_KEY to their beneficiary, the beneficiary can claim the funds after at most 6 months after the benefactor's death. The beneficiary would of course not be able to claim the funds while the user was still alive and active.

Is anyone else having their withdraw transactions cancelled with the error message "cancelled:BTSX account is not registered or memo is too long"? I didn't add a memo and my account is registered (same name as forum handle). It is especially odd because I was able to successfully send BTSX to my wallet yesterday. I've already submitted a ticket about this on BTER.

I initially had some trouble getting the Qt client to compile on Linux, but I finally figured it out. I wrote this detailed guide on the steps I took to get the client to compile on my system (Ubuntu 14.04 x86_64). It might be useful to other people who are having compilation problems, but it's also part of a question I have regarding errors that I am still experiencing with the web wallet (web wallet errors are at the bottom of this post).


The following is the procedure I followed to build on x86_64 Ubuntu 14.04 (3.13.0-27-generic):

Install prerequisite packages from repository (according to BUILD_UBUNTU.md):
sudo apt-get update
sudo apt-get install cmake git libreadline-dev uuid-dev g++ libdb++-dev libdb-dev zip libssl-dev openssl build-essential python-dev autotools-dev libicu-dev libbz2-dev libboost-dev libboost-all-dev

Download latest BitShares X code from GitHub:
mkdir ~/bitshares
cd ~/bitshares
git clone https://github.com/dacsunlimited/bitsharesx.git
cd bitsharesx
git checkout 0.2.1
git submodule init
git submodule update

Download and install Qt 5.3.1 for Linux 64-bit from http://qt-project.org/downloads:
cd ~/bitshares
wget http://download.qt-project.org/official_releases/online_installers/qt-opensource-linux-x64-1.6.0-4-online.run
chmod +x qt-opensource-linux-x64-1.6.0-4-online.run
./qt-opensource-linux-x64-1.6.0-4-online.run
I used the GUI installer to install to ~/bitshares/Qt with the default installation options.

Download and install Node.js v0.10.29 from http://nodejs.org/download:
cd ~/bitshares
wget http://nodejs.org/dist/v0.10.29/node-v0.10.29-linux-x64.tar.gz
tar xzf node-v0.10.29-linux-x64.tar.gz
cd node-v0.10.29-linux-x64
export PATH=/home/$USER/bitshares/node-v0.10.29-linux-x64/bin:$PATH

Install lineman and its dependencies in web_wallet folder using npm:
cd ~/bitshares/bitsharesx/programs/web_wallet
npm install -g lineman
npm install

Then, following directions from bitsharesx/programs/qt_wallet/README.md,
I configure using CMake:
cd ~/bitshares/
mkdir bitsharesx-build
cd bitsharesx-build
export CMAKE_PREFIX_PATH=/home/$USER/bitshares/Qt/5.3/gcc_64/
cmake -DINCLUDE_QT_WALLET=ON ../bitsharesx

However, CMake gave me an error with the following output:
-- The C compiler identification is GNU 4.8.2
-- The CXX compiler identification is GNU 4.8.2
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Found ZLIB: /usr/lib/x86_64-linux-gnu/libz.so (found version "1.2.8")
-- Configuring BitShares on Linux
-- Using  as BerkeleyDB root
-- Looking for: db_cxx-6.0
-- debug/usr/lib/x86_64-linux-gnu/libdb_cxx.sooptimized/usr/lib/x86_64-linux-gnu/libdb_cxx.so
-- Found BerkeleyDB: /usr/include 
-- Using custom FindBoost.cmake
-- Boost version: 1.54.0
-- Found the following Boost libraries:
--   thread
--   date_time
--   system
--   filesystem
--   program_options
--   signals
--   serialization
--   chrono
--   unit_test_framework
--   context
--   locale
-- Using custom FindBoost.cmake
-- Boost version: 1.54.0
-- Found the following Boost libraries:
--   coroutine
-- Configuring project fc located in: /home/arhag/bitshares/bitsharesx/libraries/fc
-- Configuring fc to build on Unix/Apple
-- Using custom FindBoost.cmake
-- Boost version: 1.54.0
-- Found the following Boost libraries:
--   thread
--   date_time
--   system
--   filesystem
--   program_options
--   signals
--   serialization
--   chrono
--   unit_test_framework
--   context
--   locale
--   iostreams
--   coroutine
-- Found OpenSSL: /usr/lib/x86_64-linux-gnu/libssl.a;/usr/lib/x86_64-linux-gnu/libcrypto.a (found version "1.0.1f")
** for a debug build: cmake -DCMAKE_BUILD_TYPE=Debug ..
-- Finished fc module configuration...
-- Could NOT find Curses (missing:  CURSES_LIBRARY CURSES_INCLUDE_PATH)
-- Found Readline: /usr/include 
-- Using  as BerkeleyDB root
-- Looking for: db_cxx-6.0
-- debug/usr/lib/x86_64-linux-gnu/libdb_cxx.sooptimized/usr/lib/x86_64-linux-gnu/libdb_cxx.so
-- Found BerkeleyDB: /usr/include 
-- Enabling Bitcoin Core Wallet Imports
CMake Error at /home/arhag/bitshares/Qt/5.3/gcc_64/lib/cmake/Qt5Gui/Qt5GuiConfig.cmake:15 (message):
  The imported target "Qt5::Gui" references the file

     "Qt5Gui_EGL_LIBRARY-NOTFOUND"

  but this file does not exist.  Possible reasons include:

  * The file was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and contained

     "/home/arhag/bitshares/Qt/5.3/gcc_64/lib/cmake/Qt5Gui/Qt5GuiConfigExtras.cmake"

  but not all the files it references.

Call Stack (most recent call first):
  /home/arhag/bitshares/Qt/5.3/gcc_64/lib/cmake/Qt5Gui/Qt5GuiConfigExtras.cmake:31 (_qt5_Gui_check_file_exists)
  /home/arhag/bitshares/Qt/5.3/gcc_64/lib/cmake/Qt5Gui/Qt5GuiConfigExtras.cmake:58 (_qt5gui_find_extra_libs)
  /home/arhag/bitshares/Qt/5.3/gcc_64/lib/cmake/Qt5Gui/Qt5GuiConfig.cmake:143 (include)
  programs/qt_wallet/CMakeLists.txt:16 (find_package)


-- Configuring incomplete, errors occurred!

A little bit of searching later and I figured out I needed another dependency:
sudo apt-get install libgl1-mesa-dev libegl1-mesa-dev
And, now CMake successfully finishes. It seems Qt's CMake would fail because it couldn't find libGl.so and libEGL.so on my system. They were located at /usr/lib/x86_64-linux-gnu/mesa/libGL.so and /usr/lib/x86_64-linux-gnu/mesa-egl/libEGL.so, but for some reason CMake refuses to
search for them there. Adding the above packages created symlinks to the libraries at the proper locations /usr/lib/x86_64-linux-gnu/libGl.so and /usr/lib/x86_64-linux-gnu/libEGL.so. Perhaps the symlinks alone would have been enough, but installing the packages is simpler. So, it seems these two packages should be included in the list of prerequisite packages to initially install.

I then make the web wallet first, and then the rest of the system.
cd ~/bitshares/bitsharesx-build
make buildweb
make
The compilation seems to work fine with the exception of some annoying compiler warnings which seem to me to be mostly benign.

Finally, I run the Qt client and everything appears to be working.
cd ~/bitsharesx-build/programs/qt_wallet
./BitSharesX

At this point, everything is working fine, and there is no need for the user to go further. However, I wanted to explore the other options available, such as using the web wallet through the browser directly and not needing Qt, and that is where I got errors.

I first modified "~/BitShares X/config.json" according to bitsharesx/programs/web_wallet/README.md to contain:
{
  "rpc": {
    "rpc_user": "test",
    "rpc_password": "test",
    "rpc_endpoint": "127.0.0.1:0",
    "httpd_endpoint": "127.0.0.1:0",
    "htdocs": "/home/arhag/bitshares/bitsharesx/programs/web_wallet/generated"
  },
...

Then, I run the bitshares_client with the following options:
cd ~/bitshares/bitsharesx-build/programs/client
./bitshares_client --data-dir ~/BitShares\ X/ --server --httpport 9989
The client seems to be working fine. I can use all the commands. Only problems seem to be a regularly repeating message that says a peer disconnected me because of an invalid block:
Peer <IP address>:<port> disconnected us: You offered us a block that we reject as invalid
I am not sure if this is normal behavior or not. Also when stopping the client, it crashes with a segmentation fault.

Now, with the bitshares_client running, I also run the web wallet:
cd ~/bitshares/bitsharesx/programs/web_wallet
lineman run

I am able to use my web browser to connect to http://localhost:8000/ and see the GUI interface, however nothing actually works because it gives me an RPC error at the lower left corner with an error about prefixMatchingApiProxy not being defined. The lineman process prints the following error in the terminal:
ReferenceError: prefixMatchingApiProxy is not defined
  at /home/arhag/bitshares/bitsharesx/programs/web_wallet/config/server.js:21:57
  at callbacks (/home/arhag/bitshares/bitsharesx/programs/web_wallet/node_modules/lineman/node_modules/express/lib/router/index.js:164:37)
  at multipart (/home/arhag/bitshares/bitsharesx/programs/web_wallet/node_modules/lineman/node_modules/express/node_modules/connect/lib/middleware/multipart.js:81:27)
  at /home/arhag/bitshares/bitsharesx/programs/web_wallet/node_modules/lineman/node_modules/express/node_modules/connect/lib/middleware/bodyParser.js:57:9
  at urlencoded (/home/arhag/bitshares/bitsharesx/programs/web_wallet/node_modules/lineman/node_modules/express/node_modules/connect/lib/middleware/urlencoded.js:46:27)
  at /home/arhag/bitshares/bitsharesx/programs/web_wallet/node_modules/lineman/node_modules/express/node_modules/connect/lib/middleware/bodyParser.js:55:7
  at IncomingMessage.<anonymous> (/home/arhag/bitshares/bitsharesx/programs/web_wallet/node_modules/lineman/node_modules/express/node_modules/connect/lib/middleware/json.js:72:9)
  at IncomingMessage.emit (events.js:92:17)
  at _stream_readable.js:929:16
  at process._tickCallback (node.js:419:13)

I don't know why lineman is giving me this problem. If I comment out the offending console.log function in web_wallet/config/server.js, I don't get that particular error anymore but the web wallet still doesn't work because the HTTP POST requests to /rpc don't get any response back. Have I not set things up correctly? In particular, I am wondering how the web wallet (the lineman process) knows what RPC username and password to use when making the requests.