I compare agree with is allocated according to the share held by the now, this is the love of ORA is a kind of encourage.
Topic: [ANN] ORA :: NXT 'monetary system' currency - page 32. (Read 181197 times)
@DarkhorseofNxt
Ya, it's an important discussion to have and be open about. It's good of you to bring it up!
An idea for how we could potentially tackle a "selective" distribution:
1. List A: Decide a date and/or time. On this date, a copy of the latest list of holders along with their balances is saved (every ORA holder).
2. List B: Save a copy of the final stakeholder list (that is, everyone who has originally received a stake) in the most optimal format for this purpose.
3. We let a program run through and compare both lists. Then let it create list C, consisting of all accounts with a balance of > X from list A and who is also included in list B.
4. Then we could send extra ORA to list C only. With no manual selection/filtering needed.
5. If someone has sold their stake, then buys a new one, they will still be included using this method. We only check current balance. It'd be OK with me. Though it could of course technically be abused.
I don't *think* this would be too difficult to do and could be quite an efficient method. It's an option to think about anyway. Some of it would depend on how easy it is to get an up to date, 100% accurate list of all current holders. We wouldn't want anyone who actually got a good balance and is eligible for the bonus ORA to not receive anything.
Ya, it's an important discussion to have and be open about. It's good of you to bring it up!
An idea for how we could potentially tackle a "selective" distribution:
1. List A: Decide a date and/or time. On this date, a copy of the latest list of holders along with their balances is saved (every ORA holder).
2. List B: Save a copy of the final stakeholder list (that is, everyone who has originally received a stake) in the most optimal format for this purpose.
3. We let a program run through and compare both lists. Then let it create list C, consisting of all accounts with a balance of > X from list A and who is also included in list B.
4. Then we could send extra ORA to list C only. With no manual selection/filtering needed.
5. If someone has sold their stake, then buys a new one, they will still be included using this method. We only check current balance. It'd be OK with me. Though it could of course technically be abused.
I don't *think* this would be too difficult to do and could be quite an efficient method. It's an option to think about anyway. Some of it would depend on how easy it is to get an up to date, 100% accurate list of all current holders. We wouldn't want anyone who actually got a good balance and is eligible for the bonus ORA to not receive anything.
You could do something like this :
Liste C : balance > 100,000 gets additional of 50,000
balance > 150,000 gets additional of 75,000
balance > 200,000 gets additional of 100,000
balance > 300,000 gets additional of 125,000
....
keep the rest for later distribution. (3rd round, 4th round,.... )
@DarkhorseofNxt
Ya, it's an important discussion to have and be open about. It's good of you to bring it up!
An idea for how we could potentially tackle a "selective" distribution:
1. List A: Decide a date and/or time. On this date, a copy of the latest list of holders along with their balances is saved (every ORA holder).
2. List B: Save a copy of the final stakeholder list (that is, everyone who has originally received a stake) in the most optimal format for this purpose.
3. We let a program run through and compare both lists. Then let it create list C, consisting of all accounts with a balance of > X from list A and who is also included in list B.
4. Then we could send extra ORA to list C only. With no manual selection/filtering needed.
5. If someone has sold their stake, then buys a new one, they will still be included using this method. We only check current balance. It'd be OK with me. Though it could of course technically be abused.
I don't *think* this would be too difficult to do and could be quite an efficient method. It's an option to think about anyway. Some of it would depend on how easy it is to get an up to date, 100% accurate list of all current holders. We wouldn't want anyone who actually got a good balance and is eligible for the bonus ORA to not receive anything.
Ya, it's an important discussion to have and be open about. It's good of you to bring it up!
An idea for how we could potentially tackle a "selective" distribution:
1. List A: Decide a date and/or time. On this date, a copy of the latest list of holders along with their balances is saved (every ORA holder).
2. List B: Save a copy of the final stakeholder list (that is, everyone who has originally received a stake) in the most optimal format for this purpose.
3. We let a program run through and compare both lists. Then let it create list C, consisting of all accounts with a balance of > X from list A and who is also included in list B.
4. Then we could send extra ORA to list C only. With no manual selection/filtering needed.
5. If someone has sold their stake, then buys a new one, they will still be included using this method. We only check current balance. It'd be OK with me. Though it could of course technically be abused.
I don't *think* this would be too difficult to do and could be quite an efficient method. It's an option to think about anyway. Some of it would depend on how easy it is to get an up to date, 100% accurate list of all current holders. We wouldn't want anyone who actually got a good balance and is eligible for the bonus ORA to not receive anything.
I kinda figured this is the way to. So i checked the account balances of the asset holders in nxtreporting of some of the accounts. I found a few inaccurate numbers. Hence i posted an enquiry on that in nxtreporting thread earlier today. So i would like to get that fixed first. But i havent done a check in nxtblocks.info. yet. Will do that too.
I think that is doable Mac Red.
Yes this is my biggest issue as well. If we can't get a list of balances we know for sure is perfectly accurate it's no point. We need that assurance if we're going to do things the automatic way.
@Equate
As for building the script itself to generate list C it's likely not any huge work. But it'd be done after we've all decided it's what we want.
Waaaaait. So the people who sold a little are going to be excluded from the new distribution?
Any smart John Doe lurking at the btt wild west should think about diversification. I sold about 9k at the peak to buy a few jl777hodl assets. And i decided to keep the rest untouched and every day it's worth less and less and less. Mac Red can confirm this based on my registry at the stakeholder list. I'm happy to own 157k ora's and i will hold them until it reaches 0.
This is just not fair.
Any smart John Doe lurking at the btt wild west should think about diversification. I sold about 9k at the peak to buy a few jl777hodl assets. And i decided to keep the rest untouched and every day it's worth less and less and less. Mac Red can confirm this based on my registry at the stakeholder list. I'm happy to own 157k ora's and i will hold them until it reaches 0.
This is just not fair.
Nah I was just giving an example. The reason I included balance in my argument was because people who no longer have any ORA perhaps shouldn't get receive any bonus either. But nothing's decided. Is your stance it'd be better to just distribute to all original stakeholders?
Waaaaait. So the people who sold a little are going to be excluded from the new distribution?
Any smart John Doe lurking at the btt wild west should think about diversification. I sold about 9k at the peak to buy a few jl777hodl assets. And i decided to keep the rest untouched and every day it's worth less and less and less. Mac Red can confirm this based on my registry at the stakeholder list. I'm happy to own 157k ora's and i will hold them until it reaches 0.
This is just not fair.
Any smart John Doe lurking at the btt wild west should think about diversification. I sold about 9k at the peak to buy a few jl777hodl assets. And i decided to keep the rest untouched and every day it's worth less and less and less. Mac Red can confirm this based on my registry at the stakeholder list. I'm happy to own 157k ora's and i will hold them until it reaches 0.
This is just not fair.
That minimum amount is not fixed yet.
Waaaaait. So the people who sold a little are going to be excluded from the new distribution?
Any smart John Doe lurking at the btt wild west should think about diversification. I sold about 9k at the peak to buy a few jl777hodl assets. And i decided to keep the rest untouched and every day it's worth less and less and less. Mac Red can confirm this based on my registry at the stakeholder list. I'm happy to own 157k ora's and i will hold them until it reaches 0.
This is just not fair.
Any smart John Doe lurking at the btt wild west should think about diversification. I sold about 9k at the peak to buy a few jl777hodl assets. And i decided to keep the rest untouched and every day it's worth less and less and less. Mac Red can confirm this based on my registry at the stakeholder list. I'm happy to own 157k ora's and i will hold them until it reaches 0.
This is just not fair.
I think you picked it up wrong. you can still buy back 9k to "complete" your stake for less than you sold it for so its a win win
@DarkhorseofNxt
Ya, it's an important discussion to have and be open about. It's good of you to bring it up!
An idea for how we could potentially tackle a "selective" distribution:
1. List A: Decide a date and/or time. On this date, a copy of the latest list of holders along with their balances is saved (every ORA holder).
2. List B: Save a copy of the final stakeholder list (that is, everyone who has originally received a stake) in the most optimal format for this purpose.
3. We let a program run through and compare both lists. Then let it create list C, consisting of all accounts with a balance of > X from list A and who is also included in list B.
4. Then we could send extra ORA to list C only. With no manual selection/filtering needed.
5. If someone has sold their stake, then buys a new one, they will still be included using this method. We only check current balance. It'd be OK with me. Though it could of course technically be abused.
I don't *think* this would be too difficult to do and could be quite an efficient method. It's an option to think about anyway. Some of it would depend on how easy it is to get an up to date, 100% accurate list of all current holders. We wouldn't want anyone who actually got a good balance and is eligible for the bonus ORA to not receive anything.
Ya, it's an important discussion to have and be open about. It's good of you to bring it up!
An idea for how we could potentially tackle a "selective" distribution:
1. List A: Decide a date and/or time. On this date, a copy of the latest list of holders along with their balances is saved (every ORA holder).
2. List B: Save a copy of the final stakeholder list (that is, everyone who has originally received a stake) in the most optimal format for this purpose.
3. We let a program run through and compare both lists. Then let it create list C, consisting of all accounts with a balance of > X from list A and who is also included in list B.
4. Then we could send extra ORA to list C only. With no manual selection/filtering needed.
5. If someone has sold their stake, then buys a new one, they will still be included using this method. We only check current balance. It'd be OK with me. Though it could of course technically be abused.
I don't *think* this would be too difficult to do and could be quite an efficient method. It's an option to think about anyway. Some of it would depend on how easy it is to get an up to date, 100% accurate list of all current holders. We wouldn't want anyone who actually got a good balance and is eligible for the bonus ORA to not receive anything.
I kinda figured this is the way to. So i checked the account balances of the asset holders in nxtreporting of some of the accounts. I found a few inaccurate numbers. Hence i posted an enquiry on that in nxtreporting thread earlier today. So i would like to get that fixed first. But i havent done a check in nxtblocks.info. yet. Will do that too.
https://nxtforum.org/news-and-announcements/nxtreporting-com-the-nxt-asset-exchange-portfolio-manager/msg78012/#msg78012
I think that is doable Mac Red.
@DarkhorseofNxt
Ya, it's an important discussion to have and be open about. It's good of you to bring it up!
An idea for how we could potentially tackle a "selective" distribution:
1. List A: Decide a date and/or time. On this date, a copy of the latest list of holders along with their balances is saved (every ORA holder).
2. List B: Save a copy of the final stakeholder list (that is, everyone who has originally received a stake) in the most optimal format for this purpose.
3. We let a program run through and compare both lists. Then let it create list C, consisting of all accounts with a balance of > X from list A and who is also included in list B.
4. Then we could send extra ORA to list C only. With no manual selection/filtering needed.
5. If someone has sold their stake, then buys a new one, they will still be included using this method. We only check current balance. It'd be OK with me. Though it could of course technically be abused.
I don't *think* this would be too difficult to do and could be quite an efficient method. It's an option to think about anyway. Some of it would depend on how easy it is to get an up to date, 100% accurate list of all current holders. We wouldn't want anyone who actually got a good balance and is eligible for the bonus ORA to not receive anything.
Ya, it's an important discussion to have and be open about. It's good of you to bring it up!
An idea for how we could potentially tackle a "selective" distribution:
1. List A: Decide a date and/or time. On this date, a copy of the latest list of holders along with their balances is saved (every ORA holder).
2. List B: Save a copy of the final stakeholder list (that is, everyone who has originally received a stake) in the most optimal format for this purpose.
3. We let a program run through and compare both lists. Then let it create list C, consisting of all accounts with a balance of > X from list A and who is also included in list B.
4. Then we could send extra ORA to list C only. With no manual selection/filtering needed.
5. If someone has sold their stake, then buys a new one, they will still be included using this method. We only check current balance. It'd be OK with me. Though it could of course technically be abused.
I don't *think* this would be too difficult to do and could be quite an efficient method. It's an option to think about anyway. Some of it would depend on how easy it is to get an up to date, 100% accurate list of all current holders. We wouldn't want anyone who actually got a good balance and is eligible for the bonus ORA to not receive anything.
Good idea but how soon can it be implemented.
Waaaaait. So the people who sold a little are going to be excluded from the new distribution?
Any smart John Doe lurking at the btt wild west should think about diversification. I sold about 9k at the peak to buy a few jl777hodl assets. And i decided to keep the rest untouched and every day it's worth less and less and less. Mac Red can confirm this based on my registry at the stakeholder list. I'm happy to own 157k ora's and i will hold them until it reaches 0.
This is just not fair.
Any smart John Doe lurking at the btt wild west should think about diversification. I sold about 9k at the peak to buy a few jl777hodl assets. And i decided to keep the rest untouched and every day it's worth less and less and less. Mac Red can confirm this based on my registry at the stakeholder list. I'm happy to own 157k ora's and i will hold them until it reaches 0.
This is just not fair.
@DarkhorseofNxt
Ya, it's an important discussion to have and be open about. It's good of you to bring it up!
An idea for how we could potentially tackle a "selective" distribution:
1. List A: Decide a date and/or time. On this date, a copy of the latest list of holders along with their balances is saved (every ORA holder).
2. List B: Save a copy of the final stakeholder list (that is, everyone who has originally received a stake) in the most optimal format for this purpose.
3. We let a program run through and compare both lists. Then let it create list C, consisting of all accounts with a balance of > X from list A and who is also included in list B.
4. Then we could send extra ORA to list C only. With no manual selection/filtering needed.
5. If someone has sold their stake, then buys a new one, they will still be included using this method. We only check current balance. It'd be OK with me. Though it could of course technically be abused.
I don't *think* this would be too difficult to do and could be quite an efficient method. It's an option to think about anyway. Some of it would depend on how easy it is to get an up to date, 100% accurate list of all current holders. We wouldn't want anyone who actually got a good balance and is eligible for the bonus ORA to not receive anything.
sounds good. If you want to more ORA, don't dump. Ya, it's an important discussion to have and be open about. It's good of you to bring it up!
An idea for how we could potentially tackle a "selective" distribution:
1. List A: Decide a date and/or time. On this date, a copy of the latest list of holders along with their balances is saved (every ORA holder).
2. List B: Save a copy of the final stakeholder list (that is, everyone who has originally received a stake) in the most optimal format for this purpose.
3. We let a program run through and compare both lists. Then let it create list C, consisting of all accounts with a balance of > X from list A and who is also included in list B.
4. Then we could send extra ORA to list C only. With no manual selection/filtering needed.
5. If someone has sold their stake, then buys a new one, they will still be included using this method. We only check current balance. It'd be OK with me. Though it could of course technically be abused.
I don't *think* this would be too difficult to do and could be quite an efficient method. It's an option to think about anyway. Some of it would depend on how easy it is to get an up to date, 100% accurate list of all current holders. We wouldn't want anyone who actually got a good balance and is eligible for the bonus ORA to not receive anything.
@DarkhorseofNxt
Ya, it's an important discussion to have and be open about. It's good of you to bring it up!
An idea for how we could potentially tackle a "selective" distribution:
1. List A: Decide a date and/or time. On this date, a copy of the latest list of holders along with their balances is saved (every ORA holder).
2. List B: Save a copy of the final stakeholder list (that is, everyone who has originally received a stake) in the most optimal format for this purpose.
3. We let a program run through and compare both lists. Then let it create list C, consisting of all accounts with a balance of > X from list A and who is also included in list B.
4. Then we could send extra ORA to list C only. With no manual selection/filtering needed.
5. If someone has sold their stake, then buys a new one, they will still be included using this method. We only check current balance. It'd be OK with me. Though it could of course technically be abused.
I don't *think* this would be too difficult to do and could be quite an efficient method. It's an option to think about anyway. Some of it would depend on how easy it is to get an up to date, 100% accurate list of all current holders. We wouldn't want anyone who actually got a good balance and is eligible for the bonus ORA to not receive anything.
Ya, it's an important discussion to have and be open about. It's good of you to bring it up!
An idea for how we could potentially tackle a "selective" distribution:
1. List A: Decide a date and/or time. On this date, a copy of the latest list of holders along with their balances is saved (every ORA holder).
2. List B: Save a copy of the final stakeholder list (that is, everyone who has originally received a stake) in the most optimal format for this purpose.
3. We let a program run through and compare both lists. Then let it create list C, consisting of all accounts with a balance of > X from list A and who is also included in list B.
4. Then we could send extra ORA to list C only. With no manual selection/filtering needed.
5. If someone has sold their stake, then buys a new one, they will still be included using this method. We only check current balance. It'd be OK with me. Though it could of course technically be abused.
I don't *think* this would be too difficult to do and could be quite an efficient method. It's an option to think about anyway. Some of it would depend on how easy it is to get an up to date, 100% accurate list of all current holders. We wouldn't want anyone who actually got a good balance and is eligible for the bonus ORA to not receive anything.
guys, please a question: I was trying to sell 1000 top distribution in the next wallet. My balance is 1000 but when I try to sell them, it says " not enough funds". Then I tried to sell 100 Ora but it's the same. This wallet is very unfriendly for me. Does someone know what " not enough funds" mean? I m holding my stake, I d like just to know how the wallet works. Thanks in advance for the reply
Do you have NXT in your account? you need 1 nxt for the transaction
thanks to all for the replies. Any nxt faucet address? Thanks again
http://nxtra.org/faucet/
guys, please a question: I was trying to sell 1000 top distribution in the next wallet. My balance is 1000 but when I try to sell them, it says " not enough funds". Then I tried to sell 100 Ora but it's the same. This wallet is very unfriendly for me. Does someone know what " not enough funds" mean? I m holding my stake, I d like just to know how the wallet works. Thanks in advance for the reply
Do you have NXT in your account? you need 1 nxt for the transaction
thanks to all for the replies. Any nxt faucet address? Thanks again
Options for Voting
Plus we are also discussing on a possible community project based giveways.
If you have other ideas on voting categories or options to distribute the next round, pls give your suggestions. Your voices will be heard.
Quote
Distribute to existing stakeholders - 120 (72.7%)
Use to pay for bounties & developers - 26 (15.8%)
Keep in trust for later distribution - 19 (11.5%)
Use to pay for bounties & developers - 26 (15.8%)
Keep in trust for later distribution - 19 (11.5%)
Quote
Based from Jack's proposal :
1. 10.5% top off to all 1st round stake holders. Each gets appx. 41,666 oras
2. 59.2% allocated to 2nd round registration. Aprx : 208,285,684 oras
3. 5.0% allocated to charity. = 17,591,696 oras
4. 25.3% 1st round stake holders (only accounts verified from spreadsheet) with 166,666 oras gets additional 100,000 oras.
1. 10.5% top off to all 1st round stake holders. Each gets appx. 41,666 oras
2. 59.2% allocated to 2nd round registration. Aprx : 208,285,684 oras
3. 5.0% allocated to charity. = 17,591,696 oras
4. 25.3% 1st round stake holders (only accounts verified from spreadsheet) with 166,666 oras gets additional 100,000 oras.
Plus we are also discussing on a possible community project based giveways.
If you have other ideas on voting categories or options to distribute the next round, pls give your suggestions. Your voices will be heard.
Well I'm not sure what the most optimal options would be. But here's some important notes to consider/know about:
1. If there'll be a second round of distribution (say to x hundreds users) we'll need to make sure it's plausable first, depending on where we collect the entries from.
For example, if people would vote for giving away ORA to 1000 new BTT users next month without getting flooded with puppets I'd say "good luck". This option need to be realistic. Personally I'd prefer other ways to accept totally new stakeholders, like the video idea.
2. Giving some extra ORA to accounts who are keeping their shares is a very GOOD and reasonable idea IMO.
3. The task I was assigned to do is over (pretty much, say next Thursday). Does this mean I'm going anywhere? NO. But it's something people need to consider. This has also been an extremely stressful time for me personally (nothing at my "IRL" workplace has ever been close to match). I can't promise to manage a second big round for at least 3 months for health reasons (serious). Will I still want to help out with a 2d round if needed? Yes very likely. Do we still have access to the same automatic sockpuppet filtering system as before? Of course. But keep in mind it's naturally not as secure as it was the 1st round now that anybody who applied and didn't make it will surely try other ways to get on the list (some of our edge is gone). Anyway, what I'm saying is just, don't rely on me to collect hundreds of more users anytime soon.
Mac Red has a very valid concern. Sock puppet filtering may not work the 2nd round and will cause more headache.
Well, giving selective account with x number of Ora to more than 500 account will also be very time consuming. Taking the account 1 by 1. I would say give 1 extra stack to all the first round stake holders and get on with it.
Balance of the stake we can distribute with the video idea and with any other practical ways and we can have more timeline for this. Easier to manage.
Reason i keep bringing this topic again and again is because we need a valid justification of what we want to do and some real discussion on this matter.
guys, please a question: I was trying to sell 1000 top distribution in the next wallet. My balance is 1000 but when I try to sell them, it says " not enough funds". Then I tried to sell 100 Ora but it's the same. This wallet is very unfriendly for me. Does someone know what " not enough funds" mean? I m holding my stake, I d like just to know how the wallet works. Thanks in advance for the reply
Do you have NXT in your account? you need 1 nxt for the transaction
Yes. That may be the anwser. You need 1nxt to sell/cancel token
Yup that's it, I had the same problem. You can't place an order unless you have at least 1 NXT in your account. Everything has a 1 NXT fee
Head over to the NXT faucet and send yourself some, you can get anything between 1-4 NXT. In case you wanna buy NXT, I'd suggest that you don't use Cryptsy (if you're only getting a few) as the minimum withdrawal amount is 50. Polo, you only need to buy 10
Simple solution for distributing for existing Ora holders.
1. Let decide date, for example 30th of August, 0h 00 min 00sec.
2. Then get the list of holders at this time at http://www.nxtreporting.com/shareholder.php?a=ORA+%2816194910134118257692%29&show_qnt=
3. Distribute remaining ORA assets with adequate percentage of Ora for every holder account.
The most interesting thing before distribution day will be trades between holders
1. Let decide date, for example 30th of August, 0h 00 min 00sec.
2. Then get the list of holders at this time at http://www.nxtreporting.com/shareholder.php?a=ORA+%2816194910134118257692%29&show_qnt=
3. Distribute remaining ORA assets with adequate percentage of Ora for every holder account.
The most interesting thing before distribution day will be trades between holders
Options for Voting
Plus we are also discussing on a possible community project based giveways.
If you have other ideas on voting categories or options to distribute the next round, pls give your suggestions. Your voices will be heard.
Quote
Distribute to existing stakeholders - 120 (72.7%)
Use to pay for bounties & developers - 26 (15.8%)
Keep in trust for later distribution - 19 (11.5%)
Use to pay for bounties & developers - 26 (15.8%)
Keep in trust for later distribution - 19 (11.5%)
Quote
Based from Jack's proposal :
1. 10.5% top off to all 1st round stake holders. Each gets appx. 41,666 oras
2. 59.2% allocated to 2nd round registration. Aprx : 208,285,684 oras
3. 5.0% allocated to charity. = 17,591,696 oras
4. 25.3% 1st round stake holders (only accounts verified from spreadsheet) with 166,666 oras gets additional 100,000 oras.
1. 10.5% top off to all 1st round stake holders. Each gets appx. 41,666 oras
2. 59.2% allocated to 2nd round registration. Aprx : 208,285,684 oras
3. 5.0% allocated to charity. = 17,591,696 oras
4. 25.3% 1st round stake holders (only accounts verified from spreadsheet) with 166,666 oras gets additional 100,000 oras.
Plus we are also discussing on a possible community project based giveways.
If you have other ideas on voting categories or options to distribute the next round, pls give your suggestions. Your voices will be heard.
Distribute to existing stakeholders makes sense especially the ones that did not sell.
Loyalty is not a bad thing to reward as such and give a solid userbase.
guys, please a question: I was trying to sell 1000 top distribution in the next wallet. My balance is 1000 but when I try to sell them, it says " not enough funds". Then I tried to sell 100 Ora but it's the same. This wallet is very unfriendly for me. Does someone know what " not enough funds" mean? I m holding my stake, I d like just to know how the wallet works. Thanks in advance for the reply
Do you have NXT in your account? you need 1 nxt for the transaction
Yes. That may be the anwser. You need 1nxt to sell/cancel token
guys, please a question: I was trying to sell 1000 top distribution in the next wallet. My balance is 1000 but when I try to sell them, it says " not enough funds". Then I tried to sell 100 Ora but it's the same. This wallet is very unfriendly for me. Does someone know what " not enough funds" mean? I m holding my stake, I d like just to know how the wallet works. Thanks in advance for the reply
Do you have NXT in your account? you need 1 nxt for the transaction
guys, please a question: I was trying to sell 1000 top distribution in the next wallet. My balance is 1000 but when I try to sell them, it says " not enough funds". Then I tried to sell 100 Ora, but it's the same. This wallet is very unfriendly for me. Does someone know what " not enough funds" mean? Thanks in advance for the reply
Or your ora are already in the sell list?
I didn't touch anything from when I received my stake..
Jump to: