Hi Everyone,

I don't know what the problem was,  but I wasn't informed of the platform for the event until 6 minutes before the scheduled start time. Then, when I tried to log into the mumble server, there was the following error:


I copied all the login credentials exactly from the website.
Anyhow, sorry to let everyone down.
I would be happy to do hang out via Skype or Google hang out some other time in the future. Good luck with all of your projects!

Sorry we missed you today, it appears others are having the same technical difficulty you are having.

Any update?

Is that mean, that we could keep private keys in blockchain, like private key to BTC account, which is used to create a bitcoin sidechain? 

Is that mean, that witnesses could also sign a transaction without knowing a key?

Please say yes, please say yes.

[EDIT]

Quote

...
Bitcoin Wallet
1. Decentralized private key generation – Multiple Enigma nodes locally create a segment of
the key, whereas the full key is only ever assembled by the user. No trail of evidence is left
anywhere.
2. Decentralized transaction signing – Transactions signed without ever exposing the private
key or leaving a trail.
....

@bytemaster @bytemaster @bytemaster

Using the salaries example... every witness knows their own but collectively they compute the average without revealing their
individual salaries.   This is similar to collectively calculating a signature without any one party knowing the private key. 

The problem is that the parties can still collude to calculate the private key and share it.  Furthermore, they could collude to calculate the signature on an arbitrary transactions.  In effect, it reduces to multisig. 

Quote from: jsidhu on February 12, 2016, 04:34:27 pm

It is his right.. Although id like to know if he is selling because as a dev myself i know what this means.

It may mean something for you , but it means nothing in BM's case even if he did sell . Because he can always find ways to generate more BTS to make up for the ones he sold eventually(by ....you know) . So selling at the low price doesn't mean he has no hope for BTS . It just mean he is pretty sure that he has more influence on the dilution budget than the voters think .

Of course if I sold I would have less direct influence. Also, payment via dilution for work is the same as if I payed cash for the diluted shares and then bts stakeholders got to decide where the cash was spent.   

Quote from: Empirical1.2 on February 12, 2016, 02:22:51 am

localhost just sent 5 million to Poloniex, has 32 million BTS in account who's that?

in my view BM (or close relative)

wrong on both counts.

BigChainDB is an impressive solution and certainly has a place in the market. But let's think about things from a purely information-theory point of view.

BCDB scales by adding nodes. This means the nodes are not processing the SAME information, instead each node is processing a subset of the information. 

I can reach 1 million transactions per second with Graphene through having 10 chains each operating on an independent set of data.  It could probably even all run on one computer.

There is inherently sequential business logic that cannot take advantage of BCDB's parallelism approach.

How to get a stable measurement of real world value without relying on a price feed.

Proof of Work difficulty has a long lag time relative to price changes and also has efficiency improvements factored in.

So once could use mining as an objective source that is slightly biased.... all other things being equal, efficiency gains would cause the value of a proof of work to fall over time. 

If there was a way to measure / compensate for efficiency gains in an objective manner then we would be a step closer. One basic method is to guess what the efficiency gains should be.  This will give us something closer to the truth, but still error based upon the accuracy of the model.

Another means is to have several different proof-of-work systems using different algorithms. Not all algorithms will have efficiency growth spurts at the same time. By using the algorithm that grows the least in hash power at any point in time we can remove all efficiency gains that are not universal (impacting all proof of work variants at the same time).   

Any other ideas? 

 

To be fair, speculating and trading are very different skills than software development and thus something we wouldn't necessarily use.

I get the point about eating our own dog food though.