Quote from: bytemaster on September 09, 2015, 12:40:04 pm

The idea is that the root node is "real time" and doesn't get an opportunity to buffer and reorder.  Though technically it could.   The witnesses would then decide whether or not they want to coordinate via a central service to provide higher reliability or whether they wish to remain P2P.

And how do they know the central service has not been compromised? How can they tell the difference between a poor network connection and a compromised service?

Could you have independent 3rd party services publish a merkle root hash for each new block?  The entire chain you get from any independent central service has to hash all the way up to the root.  I may be over-simplifying it, but that could validate everything...

JavaScript is easier to write / debug than C++ and more people around here can probably help improve it.

Looks like a message parameter to "this.isKnownTransaction()" was left out here:
   isKnownTransaction( message ) {
      return this.known_trxsa.has(message) || this.known_trxsb.has(message)
   }

   addKnownTransaction( message ) {
      if( !this.isKnownTransaction() )
      {
         this.known_trxsa.add(message)
         return true;
      }
      return false
   }

This would prevent transactions from being sent from the client to the upstream 'root' node.  I created an issue in github...

I see the web socket keeps a list of its clients.  I guess this means every client holds another client list just like the root node?

The BTS .9 (aka 1.0) web wallet does not support voting.  Also, this version is still for small amounts only.  The  2.0 web wallet can vote using the user interface.  We will use that when it is put into production.

Quote from: jcalfee1 on August 27, 2015, 02:01:40 am

What operating system do you prefer to run your browser and wallet on?

IMO it is this one (or derivative works).. Far from perfect, but it really is a necessity.  Ubuntu seems to be the path of least resistance and keeps the core principals intact.   I think any average awake individual will have to come to some sort of conclusion like this especially when they see their freedom and rights just slipping away due to corporate greed taking advantage of lazy people just looking for a easy fix.  I intend to keep my privacy and freedom even if takes up some of my time to learn how to use it...  Ultimately I became a console "power" user and I'm glad, I am confident this investment will pay off for the rest of my life and perhaps even then some.

http://www.ubuntu.com/about/about-ubuntu/our-philosophy

Ok, so you don't need to be a console power user..  But you know how to type.  The console is full of great ideas... nothing to run from...  At least with Ubuntu you can defer using it when necessary until you have the time and mindset to learn it...   Let me know if I can help.  I think we will be safer here in terms of security and privacy.

Is this question simply targeting on  the philosophy of OSes or do you draw conclusion for the development process from this thread? Is it of Importance on which OS the wallet is run?

Thanks and Regards,

Matthias

It has a lot to do with a program running on a local machine and being available to trust it.   The important thing is that you don't have lurking bugs or intentional back-doors.  These can surface later when more people are relying on the software.  Terms of service can't protect from this or may allow it entirely.  With some new agreements is just puts is in plan open ended english: we can upload your personal information legally.

If you protect the layer closest to you you have a lot more to work with when it comes to interacting with remote services.  We all know there are tricks that can be done to make these more trustless.  This only works if your brain is capable of intense computational power or if you have a device that you can trust to do this.  Stuff on my radar are: cars, phones, personal computers and in the future personal robotics (you have seen iRobot right?) ..

It is very hard to audit the insides of a compiled program you can mostly observe it.  Observing encrypted data that leaves your machine on a regular basis is equally difficult.  The more popular or valuable a piece of software the more of a target it is...  Software updates have been uploading data and suspected of uploading operating system file searches without the user's consent for many years.  I expect that activity not covered by terms of service is wide-spread.  If you can't audit it their is no other rational way to look at it: Guilty until proven innocent.

What would also help is if the public demands it.  No good gaming platforms?  I say put get a group effort going.  Put the pressure on hardware and software creators to fix it.  One individual's rants are likely a wast of time.  But a large group can really make a difference in a hurry.  Coordinate with in-expensive block-chain voting.  In the mean time, run games on a dedicated machine but be aware that the machine may have eyes and ears (at least it does not have legs ...). 

The synergy I would see would be to allow all users that have a bitshares wallet (hopefully many in the future) to buy storagespace with your application. But no idea how to realize that technically...

The first question is: if we encrypt the wallet with the brain key but the user has their brain key compromised, can we still keep the wallet on Sia safe?

Not an easy question but an answer could seal the deal.

It is okay to create the wallet on the new machine. This really happens locally inside of the browser just like a program you install.

This is good: "React.js Conf 2015 - Full Stack Flux"
https://m.youtube.com/watch?v=KtmjkCuV-EU

And then of course this one, very very good:
React.js Conf 2015 - Immutable Data and React
https://www.youtube.com/watch?v=I7IdS-PbEgI

And a few that are not directly react related:

(thanks merivercap@slack)
The security mistakes that will haunt your startup - Diogo Mónica, LeaseWeb Tech Summit 2015
https://www.youtube.com/watch?v=aCGR4YnFC3U

If your really studying this much, you probably need a break sometimes.  Might as well continue to pick up on useful things right?
https://www.youtube.com/watch?v=PEikGKDVsCc

How about a random sharedrop date based on 1 minute of text captured during a public mumble session?  This could be independently verified by a few of us.  I included some directions below.

Code: [Select]

/* <- ignore, this is a JavaScript comment
 *
 * Paste the text including "cat" to "done" into a Unix shell.  You should get the same hash below.
 *
cat <<-done | sha1sum
<replace with 1 minute of mumble comments from a public session>
done

d062f0e592f0f8286dc2da3eeba2dff2ee1d604d  -
*/
/*
 * You can copy paste this entire script (comments are optional) into `node` to
 * get a share drop date..  You can do the same thing live using any JavaScript
 * runner.  I created a very fast quick and dirty runner here:
 * http://javascript-runner.blogspot.com/
*/

var begin_date = new Date("Wed Aug 19 2015 13:00:08 GMT-0500 (CDT)")
var end_date   = new Date("Wed Dec 19 2015 13:00:08 GMT-0500 (CDT)")
var hash = "d062f0e592f0f8286dc2da3eeba2dff2ee1d604d"

var random_seed = parseInt(hash.substring(0,4), 16)
var random_max = Math.pow(2, 16)

// random_multiplier is a decimal number between 0 and 1 (or very close)
// For example:  0xFFFF / Math.pow(2, 16) == 0.9999847412109375
var random_multiplier = random_seed / random_max

var offset = end_date.getTime() - begin_date.getTime()

offset *= random_multiplier

var share_drop_date = new Date(begin_date.getTime() + offset)

var output = {
//random_max: random_max,random_seed: random_seed,random_multiplier,
share_drop_date: share_drop_date
}

console.log(output)
JSON.stringify(output)

//  Given a begin date: "Wed Aug 19 2015 13:00:08 GMT-0500 (CDT)"
//  An end date:        "Wed Dec 19 2015 13:00:08 GMT-0500 (CDT)"
//  And a chat log hash of d062f0e592f0f8286dc2da3eeba2dff2ee1d604d
//  You should get   {"share_drop_date":"2015-11-27T01:22:50.304Z"}


The idea here is it anyone can show up in the public mumble session and put a message and completely effective share drop date in a random way. Also that can be independently verified by more than one person by pasting the script and running it. You don't need to participate to actually know a real random date is chosen you just need to know that random people participated.   This selects a random number from 0 to 1. It has a debug statement you can enable to see if it is working.

 I can replace the dates by a blocked number and we can make the window two months. If you want version let me know.   You can verify the script as it is now and make sure that it creates the same results.