How to best perform an after-the-fact, unknown time sharedrop.

[jamesc]

Have some marketing gurus pick a loto event and lets get some recognition for it (example: nba lottery live stream)...

So instead of:
<replace with 1 minute of mumble comments from a public session>

Use:
<replace with future loto numbers from...>

[Ander]

<replace with 1 minute of mumble comments from a public session>

IMHO this is a good source of entropy .. but you may want to use a random number generator of the blockchain to select where to begin your 1-minute ..

I dont think that works.
Someone could figure out various lines of chat that hash into something that would indicate either an early or a late number.  And then they could spam chat with them, to increase the chance it would be either early or late.

[xeroc]

<replace with 1 minute of mumble comments from a public session>

IMHO this is a good source of entropy .. but you may want to use a random number generator of the blockchain to select where to begin your 1-minute ..

[luckybit]

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"}


What about the entropy? It's not a bad idea but I would have doubts that it would be random. It could do with a better seed. I would improve it by taking some random data from an external source to combine with the seed to make it really random. For example you could take the random number generated by Bitshares itself and combine it with this random seed to have very good entropy for the random seed.

In your script, allow the script to take input from a data feed.  Perhaps let the choice of data feed be configurable by the user of the script. Then combine the numbers from the data feed with the hash of the chat to produce the random date which no one involved would know.

[jamesc]

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.

[jamesc]

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"}


[sudo]

it's better to provide a easy  one-click tools sharesdrop toolkit program

[luckybit]

I'm really glad there are sharper minds than my own thinking these issues through. Not only does the approach you describe avoid the temptation of insider trading it also eliminates the basis for accusations of insider trading after the sharedrop is all said and done.

Such  accusations seem inevitable, somebody is always unhappy. This would help to avoid that. Oh sure, there will always be nay sayers and irrational FUD slingers that ignore the facts, but no scheme will ever eliminate that. The best we can hope for is to minimize the ammunition they use in their FUD cannons.

Your approach helps everyone, except perhaps people that might attempt to gain at the expense of others. G +5%ood job Ander

100% agreed here.  This is why our hangouts are open as they are--there are so many extremely intelligent people here just searching for things to build, fix and or improve.

If certain processes in the chain of events can be automated, and if the date is random, then insider trading in this instant may even be able to be provably impossible.

If a smart contract on Ethereum activates the chain of events, based on a random number generated by the Bitshares blockchain, then you could have a date range where the exact day and time of the sharedrop is not known by anyone. The smart contract wouldn't even know until it receives the random seed from the Bitshares chain, and then it would simply take that seed and shuffle the day and time.

I'm not exactly sure how best to do it but I am now convinced it is technically feasible because Ethereum is Turing complete so you can do anything you want on it.

[luckybit]

Is there a reason we couldn't use the random number generation built in to bitshares itself?

Just hash the revealed secret of the 101 (or however many witness nodes there are) blocks after the end of the sharedrop window. 

Yes this.

It cannot be built into Bitshares itself. You have to either using voting or oracles. But I do know you can do a lot of interesting things if you have time capsule cryptography, combined with oracles, and or voting.

Why? Please explain.

If it can, I'd like to know how.

Every time a delegate/witness generates a block they include the hash of a secret number.  Then on their next block they reveal the secret number, pick a new secret number and reveal the hash of that new secret number.  So every block, you get a very large number that was provably picked on that delegates last block. 

If you use 1 full delegate rotation, and hash all revealed secrets together you can know the results are random as long as at least one delegate is honest.

There is the issue of the last delegate standing, but its a rather minor one.  The final delegate will know the results of his hash prior to publishing his block, and will have two choices.  He can either publish as planned and accept that result, or he can not publish and hope that the delegate in line after him has a secret that when hashed against all previously revealed secrets will result in a better outcome for him.

I hope I explained that well enough.

If this is true then it should be trivial to make the date of the snapshot random to even the developers, if it is possible to trigger process that starts the snapshot at a random date and time. If the snapshot process were automated by smart contract then no one would have to know, not even the developers.

I don't know enough about how the snapshot process works but if it's not manual, if it's just some app people are running, then it can be automated and triggered by script. Consider the fact that Ethereum is now released and how easy it should be to host the smart contracts on Ethereum, at least in theory, it might be a good idea to integrate with Ethereum for some sort of time activated automated snapshot.

[puppies]

Is there a reason we couldn't use the random number generation built in to bitshares itself?

Just hash the revealed secret of the 101 (or however many witness nodes there are) blocks after the end of the sharedrop window. 

Yes this.

It cannot be built into Bitshares itself. You have to either using voting or oracles. But I do know you can do a lot of interesting things if you have time capsule cryptography, combined with oracles, and or voting.

Why? Please explain.

If it can, I'd like to know how.

Every time a delegate/witness generates a block they include the hash of a secret number.  Then on their next block they reveal the secret number, pick a new secret number and reveal the hash of that new secret number.  So every block, you get a very large number that was provably picked on that delegates last block. 

If you use 1 full delegate rotation, and hash all revealed secrets together you can know the results are random as long as at least one delegate is honest.

There is the issue of the last delegate standing, but its a rather minor one.  The final delegate will know the results of his hash prior to publishing his block, and will have two choices.  He can either publish as planned and accept that result, or he can not publish and hope that the delegate in line after him has a secret that when hashed against all previously revealed secrets will result in a better outcome for him.

I hope I explained that well enough. 

[luckybit]

Is there a reason we couldn't use the random number generation built in to bitshares itself?

Just hash the revealed secret of the 101 (or however many witness nodes there are) blocks after the end of the sharedrop window. 

Yes this.

It cannot be built into Bitshares itself. You have to either using voting or oracles. But I do know you can do a lot of interesting things if you have time capsule cryptography, combined with oracles, and or voting.

Why? Please explain.

If it can, I'd like to know how.

[Thom]

Is there a reason we couldn't use the random number generation built in to bitshares itself?

Just hash the revealed secret of the 101 (or however many witness nodes there are) blocks after the end of the sharedrop window. 

Yes this.

It cannot be built into Bitshares itself. You have to either using voting or oracles. But I do know you can do a lot of interesting things if you have time capsule cryptography, combined with oracles, and or voting.

Why? Please explain.

[luckybit]

Is there a reason we couldn't use the random number generation built in to bitshares itself?

Just hash the revealed secret of the 101 (or however many witness nodes there are) blocks after the end of the sharedrop window. 

Yes this.

It cannot be built into Bitshares itself. You have to either using voting or oracles. But I do know you can do a lot of interesting things if you have time capsule cryptography, combined with oracles, and or voting.

[luckybit]

What about the possibility of time capsule sharedropping?

Is it possible to randomize the precise time and duration of a sharedrop using vote functionality? For instance take 6 random patterns, and then everyone votes for one of the random patterns. The winning pattern is the lucky one which sets off a specific sequence for the logic of the time lock encryption.

No one in advance would know what pattern would win the vote unless there is collusion.
In addition no one should know what the pattern refers to other than, it would simply be to trigger the process. It would be part of a seed which could be used to trigger a process and only when the process sends a completion transaction would the sharedrop smart contract be triggered to happen.

So there could be several possible dates but no one would know which of the several dates. There could be a vote to generate entropy but no one would know the result until after the vote. Even with the result of the vote if no one knows what the vote refers to, then everyone would have to wait for the unlock code.

So the technical details, it would basically require a variation of time lock encryption.

Metaphorically it would be like writing down several notes with dates on them, storing them in a time capsule, and having it so no one knows which of the notes or dates it will be. You could leave it up to the developers to randomly choose and it would work fine but there might be some interesting implications if some algorithm outside of human control could select certain parameters.

tldr;  I'm basically asking if it is technically feasible for a developer to schedule a sharedrop at a random date, with random paramters like vesting, etc, which even they can't know, and have it be verifiable that they can't know?

http://www.hashcash.org/papers/time-lock.pdf
https://crypto.stackexchange.com/questions/606/time-capsule-cryptography

[yellowecho]

My only beef with the random sharedrops is that it could harm users that are bullish BTS and have been shorting the market during price drops. My understanding from the recent Dev Hangout is that shorts and assets aren't being sharedropped on so it could potentially harm users that believe in BTS and want it to succeed.