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.

[Ander]

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.

[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.  That last delegate/witness would have a very slight pre-knowledge, but the only options they would have is to sign the block and reveal their secret, or to skip the block, and hope the next signer had a secret they liked more. 

Naturally any nodes that missed that last block would be viewed with suspicion. 

[MrJeans]

  nice solution

[Stan]

Only brief because this had already been discussed here...

It clearly IS competing against BTS as a sharedrop target and against BTS market value.

Actually there is one argument AGAINST using BTS as sharedrop target no-one brought up yet:
If you can recall PTS prices, what exactly happened after 28th of february last year?
BTS(X) market cap was effectively taken out of the PTS market cap at the time of the snapshot and the priced tanked big time.
Because BTS are used as collateral, this may result in ... you guess it .. a black swan (of course only if the airdropping market cap is large vs. BTS's market cap)

Also, IMHO, the goal of a snapshot is NOT to drive the price up (because it will go down again eventually) .... but to honor a community.

In my opinion, snapshots nowadays only make sense if you do them without further notice .. that way you
* do not drive price up
* prevent a price tanking at the time of the snapshot
* while you are still able to drop on your valuable demographic

Just my thoughts ..

I guess having the possibility of a snapshot that could occur at any time would encourage folks not to leave their BTS on some external exchange and not to sell BTS even temporarily just to fool around promiscuously with other coins...

^^ THIS! but mainly because of what I stated in my previous post.

and here...

A sharedrop happening at a random time still results in a value drop once it is announced that the sharedrop cutoff is passed, which still results in a shock to the internal markets. 

The only difference it makes is that it allows insiders who know the date of the sharedrop to benefit greatly at the expense of everyone else, by buying BTS right before they do the  sharedrop and then dumping right after it.

Of course it depends upon who knows ahead of time, and what their motivation is.

If the only person with pre-knowledge is the dev, then I wouldn't consider it a great threat.

After all I would consider the purpose of the sharedrop to be actually getting the coins in the hands of potential adopters.

The way I had envisioned it, the block would be selected automagically a week or two before launch in some provably honest way.  The exact details are left as an exercise for the student.

The OP here did a nice job of filling in some of the details.

[Thom]

I am watching this thread like a hawk for 3 reasons:

• To gauge how widespread support for Ander's idea exists in the community
• To see if others contribute improvements to it
• To observe how Cryptonomex responds

Stan's post was one of the most brief I've ever seen him make. Don't want to read too much into that but we'll see if it's telling or not.

This idea was posted late Friday night, and it needs time to permeate into the community and the deciders at Cryptonomex. Frankly I don't see the downside and the upside is very compelling. If there are significant downsides that dwarf the benefits they need to be presented here for all to judge. This should be a community decision, not one by decree!

Too early for a poll, but that might be a worthy consideration. Since the ramifications of this decision could potentially be rather profound, it might be best to employ a UIA to more formally conduct a poll that has broader reach, like the one used to vote for or against BitShares 2.0 adoption, (I can't seem to find those 2 UIAs on bsb, nor could I find the discussion about them here on the forums with a 10 minute search effort).

[mf-tzo]

I think the sharedrop period should be far longer than 2 weeks.  I am thinking 2 months.

2 weeks is definitely very short. 2 months sounds long. 1 month as we always have done is ideal imho

[CLains]

I think the sharedrop period should be far longer than 2 weeks.  I am thinking 2 months.

I was thinking to sync it with 2.0 launch but now I realize this will be way after BitShares 2.0 launches.. Then a long period makes sense.

[bytemaster]

I think the sharedrop period should be far longer than 2 weeks.  I am thinking 2 months. 

[CLains]

Great idea Ander!

I think we MUST take care to announce the terms of the sharedrop FAR and WIDE well in advance of time A.

1) We can't fault people for using exchanges when our wallet is incomplete and without multisig and 2FA easily available.
2) We don't want exchanges getting unreasonable amounts of BTS completely for free.

The remaining question is, how far in advance must we announce before time A? I would say announcement something like 4 weeks before A and then 2 weeks between A and B.

[bobmaloney]

Great idea!

You can use as one of the inputs https://www.random.org/ random number generator. 

Doesn't PLAY offer this exact feature?

Seems like this might be a perfect opportunity to demonstrate a touch of their capabilities?

[mf-tzo]

  Ander!

[Ben Mason]

Sounds like an excellent solution!!   

[fuzzy]

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. 

[betax]

Great idea!

You can use as one of the inputs https://www.random.org/ random number generator.  When I was running the lottocharity delegate this was the basis to select forum members (that was not very successful, as I never made it to the top 100 ). The best thing is that is truly random, It cannot be cheated and stores the results.

[Thom]

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.

Yep!  Thats a big deal I think.  Gotta prevent the newmines of the world from being able to accuse the devs of insider trading.

As well as preventing the case where such accusations could be true!

[sudo]

good idea

[Ander]

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.

Yep!  Thats a big deal I think.  Gotta prevent the newmines of the world from being able to accuse the devs of insider trading.

[Thom]

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

[Stan]

So the recent discussion about Identabit wanting to sharedrop at an unknown time in order to encourage holders and avoid the spike up and spike down in BTS price which could disrupt internal markets has got me thinking about how best to do this.

The main concern, I think, is that if there is some insider or group of insiders who know what the date is, then there is a profit potential for them at the expense of everyone else.  They can wait for the time to pass, then do a big dump.  The traders could see this big dump (or actually ANY big dump) as a sign that insiders knew the time was passed, and then they could dump as well, making things worse, and cause a potential black swan.


To avoid this, we need the impact of the sharedrop to be spread evenly over a range of time.


The solution I have come up with is this:
It is announced that the share drop will occur at some random time between block number A and block number B.  (Where these are spread far apart, like a month or two).
After block B is reached, some mathematical property of the next N blocks is used in order to calculate a random number.  This number is used to choose which block was the cutoff point for the sharedrop.
(For example, multiply the hashes of these blocks together, take a mod and divide by a number to get a range from 0 to 1, multiply this by the number of blocks for the sharedrop period range, to get the specific block number for the cutoff).

Because no one could predict what those numbers would be in the blocks that are used, and because these blocks are made by a variety of delegates (maybe N=101?), no one can know in advance what time the share drop will occur.


Imagine that the market perceives the value of BTS to be X, and the value of the sharedrop to be Y.
At block A, the market will price BTS at a value of X+Y.  A quarter of the way along, the market will expect only a 75% chance of gettnig the sharedrop, and therfore prices it at X + 0.75*Y.  Halfway along its X + 0.5*Y, and when block B comes around, there is no longer any chance of the sharedrop, and the market now prices BTS at value X.

This way, the value of the sharedrop leaves BTS evenly over the course of a period of time, avoiding shocks to the market, and avoiding the possibility of insider trading.

This also encourages people to hold BTS in their own wallet throughout the duration of the sharedrop, helping to remove sell pressure.


I hope that makes sense!

Nice analysis. 

[Ander]

So the recent discussion about Identabit wanting to sharedrop at an unknown time in order to encourage holders and avoid the spike up and spike down in BTS price which could disrupt internal markets has got me thinking about how best to do this.

The main concern, I think, is that if there is some insider or group of insiders who know what the date is, then there is a profit potential for them at the expense of everyone else.  They can wait for the time to pass, then do a big dump.  The traders could see this big dump (or actually ANY big dump) as a sign that insiders knew the time was passed, and then they could dump as well, making things worse, and cause a potential black swan.


To avoid this, we need the impact of the sharedrop to be spread evenly over a range of time.


The solution I have come up with is this:
It is announced that the share drop will occur at some random time between block number A and block number B.  (Where these are spread far apart, like a month or two).
After block B is reached, some mathematical property of the next N blocks is used in order to calculate a random number.  This number is used to choose which block was the cutoff point for the sharedrop.
(For example, multiply the hashes of these blocks together, take a mod and divide by a number to get a range from 0 to 1, multiply this by the number of blocks for the sharedrop period range, to get the specific block number for the cutoff).

Because no one could predict what those numbers would be in the blocks that are used, and because these blocks are made by a variety of delegates (maybe N=101?), no one can know in advance what time the share drop will occur.


Imagine that the market perceives the value of BTS to be X, and the value of the sharedrop to be Y.
At block A, the market will price BTS at a value of X+Y.  A quarter of the way along, the market will expect only a 75% chance of gettnig the sharedrop, and therfore prices it at X + 0.75*Y.  Halfway along its X + 0.5*Y, and when block B comes around, there is no longer any chance of the sharedrop, and the market now prices BTS at value X.

This way, the value of the sharedrop leaves BTS evenly over the course of a period of time, avoiding shocks to the market, and avoiding the possibility of insider trading.

This also encourages people to hold BTS in their own wallet throughout the duration of the sharedrop, helping to remove sell pressure.


I hope that makes sense!