OK guys, I'll go back and study this more. Empirically I just don't see how the Internet would function if DNS disappeared. On the other hand, thinking back in the early days of the Internet back in the 1980's, the net functioned globally without DNS. Back then many nodes had hard coded lists of IP addresses in their hosts file though. It wasn't nearly as dynamic as today. However the TCP/IP protocol has not changed substantially since then, so I do recognize the complete picture or map if you will is not dictated by DNS alone.

One thing is for certain tho, that a single mistake in the DNS screwed up how traffic was routed, irrespective of everything else. Nothing was changed on my VPS or by my VPS provider between functional and non-functional routing of packets. Some request originators failed to reach my server while I and others had no difficulty at all.

...send a packet to the IP address of one root server and it will give you a list of IP addresses...

Those "root servers" as you call them are authoritative TLD DNS repositories. If the data they contain is wrong, how do you think packets will reach the correct destination? Perhaps if the TTL were long enough they eventually would find a way to arrive at the right place, but the ping time would probably be outrageous and the tracert long enough to circle the globe!

Regardless of the detailed mechanics at the lower levels, the effective result is that DNS influences the path packets take in reaching a target IP address, and if that path is too long they won't have time to reach their destination.

I can assure you that DNS has nothing to do with how packets are routed through the internet. If that was the case, how could you look up DNS records in the first place?

With all due respect pc, the way that "DNS records are looked up in the first place" is b/c every machine knows where to route it's packets. There is a chain of authority and every link in that chain (if it is unaware of a direct path to an IP address) passes the packet "upstream", to the next "higher authority", where it processes the packet's destination the same way. Where do you suppose those packets would go without such a hierarchy? What does "upstream" mean? It means to the closest authoritative DNS zone. They are not broadcast (except UDP packets) as in a blockchain to all nodes, that would be inefficient and waste bandwidth.

There were not multiple issues at play. There was simply no know route by machines in the "dead" zones to get to my server. The DNS was the sole problem. If an IP address was ALL that was necessary everybody could reach my server regardless of DNS and that simply wasn't the case.

I just discovered that the DNSSEC record for a domain name I bought from NAMECHEAP is screwing up resolving its address. I have had this domain in place now for over 30 days and I have not changed anything in my DNS records for most of that time. Around 2 weeks ago suddenly certain users reported the website down, tho others had no issues. I checked many places around the world and most I checked said my domain name could not be found. Most users of the website had no problems resolving the name and reaching the site.

Moreover, I gave people the IP address to try to eliminate the DNS lookup entirely and they still could not reach my website. WTF? Not even directly by IP? Yes, that's right. It seems NAMECHEAP messed up the DNSSEC record which prohibited the distribution of the correct information. I just realized that DNS is more than a lookup database of names to numbers, it is the central map of the Internet as well. DNS is not an independent name lookup service for IP addresses maintained in some other scheme or database, DNS IS the database that creates the map of Internet node interconnections.

Here all this time I thought if I had the IP address of a server and DNS went down or was unavailable I could still access the server directly by IP address. I now know that isn't true. The DNSSEC records are nothing more than additional records containing cryptographic keys used to validate legitimate requests to change the DNS data so it can be propagated around the world. That is their only function; they do not encrypt any information.

Although namecheap offers names and services in exchange for Bitcoin, I will not be purchasing any more services from them in the future. Names ARE their business and mistakes like this are severe. It represents incompetence, mismanagement or both and should never have happened.

It's really a shame too, b/c with the fierce competition in the hosting space hosting services come & go often. When that happens it can tie up domains and make their ownership questionable. Namecheap got it's start in 2000 and added hosting to it's lineup as a secondary feature. That aspect of the company is quite small compared with the name services. I have used namecheap to insulate myself from the riskier volatility of the hosting market. If a hosting company or VPS provider suddenly goes out of business without notice all I have to do is buy another and point my domain to the new one. It has minimal impact with adequate backups of the old server.

Word to the wise - you might want to find a different place to buy your domains than your hosting company or Namecheap.

I have doubts about the amount of time @svk or @abit (and even you arhag) are willing to invest for work on BitShares, when steem is attracting all the attention of the devs. Arhag, you say "Devs are paid for this..." but Kens approach to funding development would probably exclude those people due to their higher pay rate to get them interested, especially considering the opportunity costs associated with not working on steem.

Is it feasible to split true stealth implementation into 2 parts:

part 1: hiding the balance of transactions (i.e. blinded transactions)

part 2: hiding the metadata

If true stealth is the combo of parts 1 & 2, then working on part 1 first is working toward true stealth. Part 1 could be free / paid for by rate limited xanctions, part 2 for those that want / require it is optional and requires additional fees, perhaps to pay for backup storage.

Just thinking out loud here...

Quote from: Thom on April 19, 2016, 02:50:53 pm

Thoughts anyone?

I think you over-complicating it for little benefit. You can backup whatever you want to the blockchain (if it is cost effective that is) with encryption that cannot be brute forced (anymore than they can brute force the private key of your public keys). The client just needs to make sure that the key used for the encryption is derived from a 256-bit randomly generated seed. I would have an IDENTITY_SEED which is a randomly generated 256-bit number represented in the form of a sequence of dictionary words that you backup and keep somewhere safe (paper backup and flash drive stored in multiple safe locations). The IDENTITY_SEED plus an optional passphrase (that you must be able to remember if you choose to use it) is used to ultimately derive all the relevant keys (owner keys, active keys, blockchain backup keys, etc.). Most keys would ideally be deterministically derived using simple incrementing indices so that recovery is trivial and doesn't bloat the blockchain with many backups of new keys. For those keys that are non-deterministic, the client would back it up to the blockchain after encrypting the payload using locally stored private keys that have full 256 bits of entropy (and are deterministically derived from IDENTITY_SEED). Then restoring from scratch becomes possible as long as the user can retrieve their IDENTITY_SEED.

Thanks for taking the time to comment arhag. I'm no expert on cryptography, but it sounds like you and @bytemaster disagree about the viability and security of using the blockchain as the wallet backup medium. My perspective was similar to what you said in your first few sentences above, until BM came along the other week and said the encryption wasn't that safe against brute force methods. That was very surprising to hear actually. He explained an important difference was the delays imposed between each guess attempt by front door time outs and other measures which wouldn't exist in a blockchain backup scenario. It makes sense on the surface, but if such measures are so important in the security of the encryption which is the core security mechanism of the entire blockchain, it's far weaker than I thought. Frankly that seems highly unlikely.

Perhaps I misunderstood the weakness BM was concerned with. Perhaps it primarily rests on the identity_seed. No encryption is worth its LSBit if the encryption key used to generate the pub / priv pairs is weak. That is ALWAYS an issue, that can never be avoided. It's a fundamental concern, however decentralized wallets on computers everywhere are not readily accessible and thus are not subject to direct, repeated trials of potential key guesses to unlock the wallet. That changes when the wallet is on a public blockchain, thus my "elaborate" scheme to A) obfuscate the account owner of the wallet with the backup and B) to decentralize the backup data to prevent direct access to it.

choose whatever account names you want without creating them...

And just how do you do that? There's got to be some way to tell the minors where to put the steem they create, so "choosing" must require a wallet command. In BTS there is a create_account_with_brain_key, but that same cmd does not exist in this steem wallet. The steam wallet has 2 create_account commands:

create_account(string creator, string new_account_name, string json_meta, bool broadcast)

create_account_with_keys(string creator, string newname, string json_meta, public_key_type owner, public_key_type active, public_key_type posting, public_key_type memo, bool broadcast)
It isn't obvious which one should be used or what the arguments should be for "creator" or "json_meta". I have assumed "json_meta" to be an empty string value, same for "creator" and that dashes in the name are OK. I have tried a number of variations all of which produce an error.

I'm straddling 2 systems atm and can't login to the slack channel, but I have an invite waiting now.

Quote from: Thom on April 17, 2016, 04:56:34 pm

Surprised nobody commented about the value these vested funds represent as I did. What good does delaying the vesting? The major point of vesting is to retain talent, and that aspect is mostly gone as empirical said. Same with deleting them. Sure that counters inflation, but how significant is that in the bigger picture? That primarily makes sense to the anti-dilution crowd, who offer zero input on how to pay for sustaining this ecosystem let alone improving it. They seem to loose sight of the fact their holding will become worthless if the ecosystem dies or cannot be maintained. Maybe the illusion of protecting their holdings is blinding them to the slow death that zero tolerance dilution will bring.

You could make the vesting period 5x longer and really slow the downward pressure.  You could also just stop the whole process for X years. 

What good would this do?  It would slow/stop the dilution that is apparently bleeding BTS.  My understand that is the objective of the suggestion in this thread. This would go further in the "good" it does.  It would keep people from saying their BTS was stolen from them.  Stolen from people who paid for the development of BTS2. My approach at least seems morally acceptable and is not blatant theft.

I see, that makes sense, total sense. I wasn't aware that the recipients of the vested BTS were selling them, or a significant portion of them, such that it has been negatively influencing the market. If that is indeed the case then delaying the vesting is a better solution, tho it is also changing the rules so is also quite controversial.

So much better than outright theft, whether that be to burn the unvested shares or use them for some other purpose.

The bottom line I think is the decision to do this is all about ethics and integrity, not about practicality.

Is self preservation ever an excuse for theft?

If self preservation is a rational basis for violence, even violence leading to the death of the aggressor,  which is the equivalent of theft of life, then it follows that the answer is yes, if survival is at stake theft is a rational response to what is threatening survival. Is it overly dramatic to apply that to the question at hand? If not there is no sound basis for the action proposed.

Although the case empirical made for eliminating the vesting and stopping future delivery of those shares is based on a failure of that vesting to achieve it's goal, that cannot be viewed as a good reason for taking the proposed action. As I said before, the contract was flawed, but it isn't reasonable to change the contract retroactively and that is exactly what this is.

Now that I've thought about this more and boil it down to the essentials, I find it difficult to see the present situation as one that threatens the survival of the ecosystem and so theft should be off the table IMO.

As to lengthening the vesting period, that retroactively violates the past agreement and this will negatively impact the integrity and trust others will have in BitShares and by induction the members of this entire community.