I don't think using CoinJoin or Mixing to directly send funds to exchanges or casinos is the good thing to do. Some platforms don't want to get troubles and they don't want the others compromise their platforms as the one for freely mixing coins from any sources (legal or illegal or shady sources). Some casinos apply the same approach as Binance, returning funds back to owners if they feel transactions are illegal. 14.7. We reserve the right to apply a wagering requirement of at least one time the deposit amount if we suspect the player is using our service as a mixer. It is strictly forbidden to use our service for any other purpose than entertainment.
14.8. If a user who has deposited funds on Bitlser refuse the KYC verification procedure and/or the wagering requirement, his funds will be sent back to the address from which they come, to make sure that he didn't use Bitsler to mix his coins
I don't experience it myself (I don't want to take risks), above is what I read in TOS of Bitsler.  |
|
|
|
I am trying to access my Electrum wallet by am unable to locate any login details aside from my wallet's encryption key. Is there any way to use this key to access the wallet?
You gave us very limited information on your case. Something you should present clearer: - Do you use your Electrum on computers or on mobile devices?
- You should differentiate between mnemonic seed, wallet password
- Encryption key, what is this? Would you mind clarify it a little bit, please. But do remember not post anything exactly what is yours. What you we need is format of your 'encryption key'.
Encryption key is a very strange term, in case of Electrum, that is a SPV wallet and secured with seeds, mnemonic seeds, more correctly. So, you should give us the first two things: - Computers or mobile devices *
- Giving us exactly the format of your encryption key. Format of your key, not your key.
*: On mobile devices, you only need PIN code ( 6 numbers), not password. If the encryption key you meant is private key, there are guides for you:
If OP lost both seeds and (passwords - on computers; or PINcode - on mobile devices), his fund will be lost and can not be recovered. Remember that passwords or PINcode is the secondary protection and play their roles to prevent hackers or bad guys get access to your wallet that secured by your seeds. If you disclose your seeds publicly, anyone can get access to your wallet, without needs to know your passwords or your PINcode. |
|
|
|
I don't know whether there are available scripts to do it with Electrum wallet or not, but if you open your Electrum wallet, you will get notifications for new transactions, both receiving and sending (when you send your coins away). Electrum wallet is a SPV and much lighter than Bitcoin Core, because it only download block headers, than cost 80 bytes for each block only. In Electrum, you can use Filter options (for History feature). - Activating the Filter option (Wallet > History > Filter)
- Using the History sub-tab
- Clicking on All / Specific year / Custom *
- After choosing Custom, you have to choose the start and end days for the period in which you want to get transaction history.
*: By default, it shows all of your transaction history, whole time, but you can narrow down the observing period by choosing either specific year or (start and end days with Custom) for your interests. I think you can also export your history: Wallet > History > Export (to .csv). The export file will contain some variables for you: transaction_hash, label (of your addresses), confirmations, and timestamp. You can sort your transactions out, over timestamp, label, and confirmations. If you filter directly on Electrum, it does not allow you to do multi-filter (by timestamp, and label and the others, so you have to do it handy.
What I present is for offline with export data, but I guess you can write some code to do it, in real-time (not sure). I hope my information give you some ideas to build up your scripts (I guess it is possible). |
|
|
|
From the reply of admin yesterday, I think now it is a very good time to think of a consistent format for the forum's data dumps. Each dataset has different variables inside, but I think all of them should be connected with only common variable (at least one variable) - userid. Username, no matter it is username or display name or both will result in differences when connecting different datasets dumped by the forum. For additional data dumps, it is not the priority and I am not in a position to ask for it too much, but for current data formats, a small adjustment: from username to userid will be good. LoyceV asked for this change too: https://bitcointalk.org/index.php?topic=5104467.msg53551686#msg53551686 |
|
|
|
As we know, more and more users changed their usernames over time. I have not been on the forum for too long enough to know all the changes of username-changing process. From what I know of, it seems over many months, username changing requests only accepted in early period of the forum. After that only VIP members and someone who have really convincing reasons will be granted by theymos. However, recent months, we've witnessed more and more users got granted from admin to change their usernames to new ones. It is their personal problems and desire, so I congratulate them for what they have done. But there are some things to consider: - After the old username changed to new one, the former one will be able to reuse by the others
- Are there risks of compromises on former username (scam/ fake/ clone)?
- What will happen with the person who take over the formerly usernames of the others (especially reputable ones, but the question is for all kind of users) ?
My suggestion:- Formerly usernames should be perma-locked and can not be reused by anyone else, except the initial owners of those usernames.
- If the 1st suggestion will not be accepted, how about solutions for the person who take over formerly usernames?
I believe the 1 st position can be done if theymos has time to code and will be convinced with my suggestion. I know there is indirect solution for it: Leaving negative trust feedback on such accounts, but it requires community efforts as well as time to do that. In the meantime, who knows scammers can scam some naive people.
Answered by theymos, so I locked it and deleted unnecessary parts. Thank you for the answer, admin. I am also sorry to people who changed usernames for privacy, not for appearance, if I did something wrong. |
|
|
|
the raw block sizes are approximately 1 MB that is usually from around 950 kB to around 1.5 MB
and the block headers are fixed at 80 bytes exactly.
that is why the size of the block headers that an SPV client such as Electrum downloads is easily calculated and rises linearly with a flat line (block count * 80 = 612149 * 80 = 48,971,920 bytes)
Thank you for the exact figures, that is why I use around for that estimation. As you wrote, I should use correct words in my post, approximately, for block size.  It requires around 1000 times less than Bitcoin Core in terms of storage to run it.
|
|
|
|
One more important technical specification for SPV wallet is: It requires around 1000 times less than Bitcoin Core in terms of storage to run it. Because SPV wallet does not download the full blockchain, full blocks. What SPV wallet does is downloading the block headers. A quick comparison: - a full block: 1 MG
- a block header: < 1 KB
|
|
|
|
I know the site today when I saw it with its campaign launch. Because gamblers tend to lazy to read rules, I pointed out some vital rules for you (for the rest, read more at https://luckyb.it/terms-of-service and https://luckyb.it/faq) Some quick notes for withdrawals:- Fee: 0.00005 BTC. I guess it is a fixed withdrawal fee, and does not depend on how much your withdrawal is, not sure.
- Minimum - maximum per one withdrawal: 0.002 BTC - 50 BTC.
- Processing time: within 1 business day
- Users are not allowed to withdraw Bitcoins if they haven’t made at least one deposit. We have to enforce this rule for security reasons. (on FAQ page)
Point #9. Verification Checks and Identification Documentation
The good news is if you fail with this process, underage, for example, your deposits will be returned.
Some restricted territories:means Curacao, the United States of America; Australia; Netherlands; France; Dutch West Indies; UK; Germany, and any other jurisdiction that prohibits your use of the Services under the laws of that jurisdiction;
|
|
|
|
Mmmm 97 transactions now who received them  For the past receivers, I don't comment, but for the next one, I believe that nullius will be the next one. He came back after 2 years. Forking hell that is impressive dude - 1K merits with under 200 posts!
i'm out of merits otherwise I would give you 50 just to piss some people off
|
|
|
|
Okay. Thank you all with today information. Your replies boosted me to think of adding a new column - ex-moderators. I think it is relevant to add into the table in OP. Because the thread is for history of local boards, and we already have birthday, adjusted birthday, so now we should split the details for moderators into: - Moderators: for current ones.
- Ex-moderators: for past ones.
One more thing to adjust for the table is adding URL links to those (ex-)moderators' profile pages. I am going to let you know when I updated the OP.
As being said: Go locals, if you find any detail incorrect or find new ones, please don't hesitate to let me know.
Lastly, if you need more details on merit distribution (a bit off-topic) on your local boards, let's visit that one (quoted below) and contact me if you need more details or want to translate that whole thread or specific parts of posts inside it or adjusting labels, titles on plots into your local languages. By now, I made analyses for daily merits over five local boards only: Russia, Indonesian, German, Turkish and Français. If you need more for weekly/ monthly merits, please contact me. |
|
|
|
so 0.08% transactions are consuming 2% of the total merit. 2% is a lot. Post the stats os the total merited sent in 50 merit transactions. I don't how much it will be, but it is certainly a lot. 5k merit? 10k merit? Is it still not relevant now?
Now look at the stats of the 50 merits transaction on each user total merit balance. If a guy who received a transaction of 50 merit, and that represents 70% of his total earned merit, do you still think that is not relevant?
Excludes all of theymos' transactions (excludes his 50-merit transactions, of course) + excludes 50 merit transactions of the others within the active period of the Art contest, we have 97 ones, that have sum of total merit values up to 4850 merits (see total_cat). The tptal amount of merits account for 1.9% (see p_meritcat) of total values of all merits (at 253341 - see total). In frequency (or also called as number of transactions), there are 97 transactions left (see meritcat_count), which account for 0.1 % (see at p_count) of 143977 number of transactions in total (see total_count). For data interpretation, I have no additional comment. +--------------------------------------------------------------------------------------+
| merit_cat total total_cat p_meritcat total_count meritcat_count p_count |
|--------------------------------------------------------------------------------------|
1. | 1 253341 101257 40 143977 101257 70.3 |
2. | 3 - 9 253341 77630 30.6 143977 18382 12.8 |
3. | 2 253341 44682 17.6 143977 22341 15.5 |
4. | 10 253341 12740 5 143977 1274 .9 |
5. | 50 253341 4850 1.9 143977 97 .1 |
|--------------------------------------------------------------------------------------|
6. | 11 - 19 253341 4262 1.7 143977 297 .2 |
7. | 20 253341 2660 1 143977 133 .1 |
8. | 31 - 49 253341 2047 .8 143977 52 0 |
9. | 25 253341 1100 .4 143977 44 0 |
10. | 21 - 24 253341 688 .3 143977 31 0 |
|--------------------------------------------------------------------------------------|
11. | 30 253341 840 .3 143977 28 0 |
12. | 26 - 29 253341 689 .3 143977 25 0 |
13. | <0 253341 -104 0 143977 16 0 |
+--------------------------------------------------------------------------------------+
|
|
|
|
All is clear now, OP have Bitcoin on test net, that has zero-value. To help OP understand his situation better, I gave the image. I believe OP see the notification when setting testnet wallet up (but maybe he did not remember). The Legacy wallet address (on test net) will be like this. On the tab header of the wallet, you see: Electrum 3.3.8 Testnet. It emphasizes Testnet. See Bitcoin Testnet. Activate, experience it, but don't trade and get scammed. |
|
|
|
One of the obvious drawbacks to giving a lot of merit that's supposed to be for overall good posting is that it'll get questioned, as it did in this case. That post linked to in the OP didn't deserve 50 merits IMO, but I see where TMAN was coming from.
I agree with you on this point. TMAN is a good source, not only because he helped me but also what he did for the other good posters in the community. Being a source is kind of official task and somehow it puts pressure to finish works as sources. If we look positively on what TMAN has done, we might agree with him on this approach, only because his lack of time and his past right decisions to dump merits on very good posters. I have not observed TMAN but occassionally when I saw him gave away 20 - 30 - 50 merits to the others, all of them deserve those merit dumps. The latest one, that resulted in the drama is TMAN dumped merits on the bad OP, and it is a root cause. No one at their first glance, spending time to look at post history of OP, they simply and only look at the bad OP's contents and the 50-merit transaction. Gettting merit dumps are always much happy, I know. I remembered the first time I got 14 merits dumped by actmyname in 2018, it's my sweet memory. Who have not yet experienced such dumps are jealous with the others (please don't deny that). But to be honest, with or without such merit dumps (from TMAN or the others), I am going to rank up, obviously.
In a summary, I suggest that if sources are lack of time to scan the forum and find good posts to dump merits; they should choose at least a good poster, scan post history of that one, then dump merits (10, 20, 50, it depends) on one of good posts of that one. It will not cause any drama, I believe. Drama causes some users withdrawn their roles as sources (at least Vod). Have you ever imagined TMAN's source-withdrawal will be good for the forum? Being a source is a silent work, without payment and you guys ask for too much, IMO. |
|
|
|
UID -> name, merit, potential activity, posts
post ID -> topic ID, time, UID
topic ID -> board ID, first post ID
board ID -> board name
The new year, so I bump it to ask for additional data dump granted by theymos. Besides these formats above, I ask for this one (for merit data): time amount msg user_from user_to boardid
1516831941 1 2818066.msg28853325 35 877396 24
I already collected the boardid, so if the merit data has only one additional variable for board's ID ( boardid), it will eliminate the need to scrap data (from LoyceV's help) each 6 months. Although I don't know the others need such variable in data dumps or not. For some sorts of analyses like these: |
|
|
|
I made my second post on this, with some clarification, please add that one in your OP, and my first post edited a little too (with some clarifications). As I wrote in my analyses, I don't see serious things with 50-merit transactions (I could be wrong). Especially if we look at how many of such transactions gave away to shitposters. Don't let the shitposters affect the good-posters. I don't know, but as theymos said he never sticks to anything so the community's complaints might cause some changes. I am never completely tied to anything, but let's try this for at least a few months and seehow it works.
|
|
|
|
It is curious how people make different analysis in the same data.
It's easy. There are two ways to do that: - Replacing all transactions relate to theymos as missing values, that treated as zero or not-counted when making sum of transaction values as well as count of number of transactions.
- Dropping all transactions relate to theymos from the initial dataset.
That's not 3% of all merit transactions. I guess tranthidung meant 3% of all merits.
You are right. In my initial post, 3% and 2% are for frequency or number of 50-merit transactions per total number of transactions made in the same period. I forgot to make a note on that, to differentiate between percent for number of transactions and values of transactions. Edited that post today, please check. According to tranthidung's data there have been totally 146290 merit transactions. The number of 50 merit transactions is 166 which is only 0.11% of all transactions.
Excluding all of theymos' transactions (excludes his 50-merit transactions - of course), the percent of such transactions falls to 0.08%. Also note that many of these transactions were done in the art contest.
The Art Contest initially opened on 17 th October 2019 and ended on 2 nd December 2019. Let's assume all 50-merit transactions in that period are all from the Art Contest (they actually came from threads beyond the Art contest), then dropped all of those 50-merit ones in that period. Results (Without the assumed-Art-contest-related transactions)50-merit transactions account for 1.9% (in values - p_meritcat) or 0.1% (in number of transactions - p_count). Not all transactions within the Art contest excluded, I only did it for 50-merit transactions in that period. +--------------------------------------------------------------------------------------+
| merit_cat total total_cat p_meritcat total_count meritcat_count p_count |
|--------------------------------------------------------------------------------------|
1. | 1 253341 101257 40 143977 101257 70.3 |
2. | 3 - 9 253341 77630 30.6 143977 18382 12.8 |
3. | 2 253341 44682 17.6 143977 22341 15.5 |
4. | 10 253341 12740 5 143977 1274 .9 |
5. | 50 253341 4850 1.9 143977 97 .1 |
|--------------------------------------------------------------------------------------|
6. | 11 - 19 253341 4262 1.7 143977 297 .2 |
7. | 20 253341 2660 1 143977 133 .1 |
8. | 31 - 49 253341 2047 .8 143977 52 0 |
9. | 25 253341 1100 .4 143977 44 0 |
10. | 21 - 24 253341 688 .3 143977 31 0 |
|--------------------------------------------------------------------------------------|
11. | 30 253341 840 .3 143977 28 0 |
12. | 26 - 29 253341 689 .3 143977 25 0 |
13. | <0 253341 -104 0 143977 16 0 |
+--------------------------------------------------------------------------------------+
Example: You waste time and thought, energy to make statistics on the Bitcointalk community almost every day.
Why you don't deserve 50-100 Merit, that's the question right now.
It does not matter with me, honestly. I am sad a little but truly said, it does not a big issue. I do this because I love stats. Merits come, good. Merits don't come, not too bad. There are some potential explanations for this (about my threads): - Boring, with figures and charts.
- Contains some difficult statistical words (for someone who don't know such terms, and who use English as a second language. They don't know what are median and interquartile range, ie.)
- Repeat what the others do without any additional interesting points (fortunately, I always tried to put additional things, that I though helpful).
- My current merit record: Maybe. I received lots of merits for my threads weeks ago but it has been slow down when my total merit point crossed 1000. Who knows?
For example again, the account mentioned by @ETFbitcoin, johank, after spending 125 Merit, the account is no longer used, this also happens to this account, maduI don't go in-depth with these cases, but basically meriters can not control the future activities of receivers. If you keep your mind as freshy as possible and look at the page: Top senders to permanbanned users, last 180 days. Who is on the top? theymos. So, what's wrong with theymos? Has he abused the merit system by sending merits to 105 users who were permanbanned later? |
|
|
|
Something like that (for real use cases of data on ranks): Where receivers received merits from, and meriters sents merits to. I moved further and complicated things from your data and DdmrDdmr's Merit Dashboard. From the results, I think we have interesting overview, but such things should be played around yearly (if we do). But for userrank, DdmrDdmr has it already so if it costs your time, and some the other things, it is not worth to pay some kinda of resources on it. I agree. |
|
|
|
From stats, I don't see serious thing with 50-merit transactions!On the one hand, they (in number of transactions) account for about 0.11% (includes theymos' transactions) or 0.08% (excludes theymos' transactions) of all merit transactions. On the other hand, in values of transactions, they account for about 3% (includes theymos' transaction values) and 2% (excludes theymos' transaction values). Why are we so serious about it?
Over the period from 2018 to 2020 (a few days of this year), we have 284993 merit transactions, in total. It seems there is a half-split between 2018 and 2019, it is good. year | Freq. Percent Cum.
------------+-----------------------------------
2018 | 138,703 48.67 48.67
2019 | 145,301 50.98 99.65
2020 | 989 0.35 100.00
------------+-----------------------------------
Total | 284,993 100.00
Now, drop the year 2018, and let's how merit transactions distributed. Period: 01/01/2019 to 03/01/2020. In terms of number of transactions, theymos' transactions (received and gave away) account for 1.6%. theymos | Freq. Percent Cum.
------------+-----------------------------------
no | 143,993 98.43 98.43
yes | 2,297 1.57 100.00
------------+-----------------------------------
Total | 146,290 100.00
However, theymos' merit transactions dominate in the value of 50, his transactions account for 31.9% (53 transactions per 166 transactions with 50 merits for each in that period). Categorisation merit transactions into groups:With theymos' transactions included: merit_cat | Freq. Percent Cum.
------------+-----------------------------------
<0 | 16 0.01 0.01
1 | 102,226 69.88 69.89
2 | 22,690 15.51 85.40
3 - 9 | 18,911 12.93 98.33
10 | 1,409 0.96 99.29
11 - 19 | 412 0.28 99.57
20 | 164 0.11 99.68
21 - 24 | 40 0.03 99.71
25 | 74 0.05 99.76
26 - 29 | 30 0.02 99.78
30 | 45 0.03 99.81
31 - 49 | 107 0.07 99.89
50 | 166 0.11 100.00
------------+-----------------------------------
Total | 146,290 100.00
With theymos' transactions excluded merit_cat | Freq. Percent Cum.
------------+-----------------------------------
<0 | 16 0.01 0.01
1 | 101,257 70.32 70.33
2 | 22,341 15.52 85.85
3 - 9 | 18,382 12.77 98.61
10 | 1,274 0.88 99.50
11 - 19 | 297 0.21 99.70
20 | 133 0.09 99.80
21 - 24 | 31 0.02 99.82
25 | 44 0.03 99.85
26 - 29 | 25 0.02 99.87
30 | 28 0.02 99.89
31 - 49 | 52 0.04 99.92
50 | 113 0.08 100.00
------------+-----------------------------------
Total | 143,993 100.00
All of above are for number of transactions, now let's move on with values of transactions, over categories. In total of values, we have 268283 merits distributed in that period (from 17/10/2019 to 2/12/2019, with somewhat delayed effects too). +--------------------------------------------------------------------------------------+
| merit_cat total total_cat p_meritcat total_count meritcat_count p_count |
|--------------------------------------------------------------------------------------|
1. | <0 268283 -104 0 146290 16 0 |
2. | 1 268283 102226 38.1 146290 102226 69.9 |
3. | 2 268283 45380 16.9 146290 22690 15.5 |
4. | 3 - 9 268283 80078 29.8 146290 18911 12.9 |
5. | 10 268283 14090 5.3 146290 1409 1 |
|--------------------------------------------------------------------------------------|
6. | 11 - 19 268283 5912 2.2 146290 412 .3 |
7. | 20 268283 3280 1.2 146290 164 .1 |
8. | 21 - 24 268283 892 .3 146290 40 0 |
9. | 25 268283 1850 .7 146290 74 .1 |
10. | 26 - 29 268283 825 .3 146290 30 0 |
|--------------------------------------------------------------------------------------|
11. | 30 268283 1350 .5 146290 45 0 |
12. | 31 - 49 268283 4204 1.6 146290 107 .1 |
13. | 50 268283 8300 3.1 146290 166 .1 |
+--------------------------------------------------------------------------------------+
Sorting them out, descendingly based on p_meritcat. The group for 50-merit-per-transaction is ranked at the 5 th position, with only 3.1%. +--------------------------------------------------------------------------------------+
| merit_cat total total_cat p_meritcat total_count meritcat_count p_count |
|--------------------------------------------------------------------------------------|
1. | 1 268283 102226 38.1 146290 102226 69.9 |
2. | 3 - 9 268283 80078 29.8 146290 18911 12.9 |
3. | 2 268283 45380 16.9 146290 22690 15.5 |
4. | 10 268283 14090 5.3 146290 1409 1 |
5. | 50 268283 8300 3.1 146290 166 .1 |
|--------------------------------------------------------------------------------------|
6. | 11 - 19 268283 5912 2.2 146290 412 .3 |
7. | 31 - 49 268283 4204 1.6 146290 107 .1 |
8. | 20 268283 3280 1.2 146290 164 .1 |
9. | 25 268283 1850 .7 146290 74 .1 |
10. | 30 268283 1350 .5 146290 45 0 |
|--------------------------------------------------------------------------------------|
11. | 26 - 29 268283 825 .3 146290 30 0 |
12. | 21 - 24 268283 892 .3 146290 40 0 |
13. | <0 268283 -104 0 146290 16 0 |
+--------------------------------------------------------------------------------------+
Lastly, let's take a look at 50-merit transactions over months. Looking at them (by months), we clearly see the domination of months when Art Contest for the 10th anniversary happened. +---------------------------------------+
| forumtime month amount |
|---------------------------------------|
3159. | 27dec2019 21:48:43 2019m12 50 |
3160. | 27dec2019 21:46:42 2019m12 50 |
6962. | 20dec2019 13:42:16 2019m12 50 |
|---------------------------------------|
18505. | 25nov2019 17:17:03 2019m11 50 |
19604. | 23nov2019 19:54:30 2019m11 50 |
19939. | 23nov2019 12:09:31 2019m11 50 |
20447. | 22nov2019 21:44:37 2019m11 50 |
20493. | 22nov2019 20:38:25 2019m11 50 |
20594. | 22nov2019 19:55:44 2019m11 50 |
20882. | 22nov2019 17:38:02 2019m11 50 |
21566. | 22nov2019 09:14:01 2019m11 50 |
21776. | 22nov2019 05:39:11 2019m11 50 |
21792. | 22nov2019 05:29:16 2019m11 50 |
21810. | 22nov2019 05:13:57 2019m11 50 |
21826. | 22nov2019 05:05:19 2019m11 50 |
22852. | 21nov2019 06:17:52 2019m11 50 |
22921. | 21nov2019 05:32:00 2019m11 50 |
22997. | 21nov2019 04:33:25 2019m11 50 |
22999. | 21nov2019 04:31:49 2019m11 50 |
23005. | 21nov2019 04:27:30 2019m11 50 |
23028. | 21nov2019 04:17:14 2019m11 50 |
23051. | 21nov2019 04:03:02 2019m11 50 |
23080. | 21nov2019 03:23:40 2019m11 50 |
23083. | 21nov2019 03:21:47 2019m11 50 |
23122. | 21nov2019 02:21:40 2019m11 50 |
23124. | 21nov2019 02:17:13 2019m11 50 |
23161. | 21nov2019 01:36:14 2019m11 50 |
23188. | 21nov2019 01:13:42 2019m11 50 |
23191. | 21nov2019 01:11:23 2019m11 50 |
23218. | 21nov2019 00:37:42 2019m11 50 |
23222. | 21nov2019 00:31:38 2019m11 50 |
23268. | 20nov2019 22:48:14 2019m11 50 |
23292. | 20nov2019 22:20:02 2019m11 50 |
23305. | 20nov2019 22:07:20 2019m11 50 |
23368. | 20nov2019 21:02:17 2019m11 50 |
24776. | 19nov2019 04:31:24 2019m11 50 |
24781. | 19nov2019 04:27:32 2019m11 50 |
24804. | 19nov2019 04:02:52 2019m11 50 |
24867. | 19nov2019 03:20:33 2019m11 50 |
24950. | 19nov2019 02:20:35 2019m11 50 |
24966. | 19nov2019 02:06:04 2019m11 50 |
24977. | 19nov2019 01:53:41 2019m11 50 |
25019. | 19nov2019 01:23:58 2019m11 50 |
25049. | 19nov2019 00:56:05 2019m11 50 |
25247. | 18nov2019 20:28:09 2019m11 50 |
25291. | 18nov2019 19:53:04 2019m11 50 |
25314. | 18nov2019 19:33:10 2019m11 50 |
25326. | 18nov2019 19:26:16 2019m11 50 |
26332. | 17nov2019 14:12:21 2019m11 50 |
26479. | 17nov2019 07:36:47 2019m11 50 |
27604. | 15nov2019 18:52:16 2019m11 50 |
28071. | 15nov2019 11:51:14 2019m11 50 |
29280. | 14nov2019 00:31:46 2019m11 50 |
30494. | 10nov2019 21:07:57 2019m11 50 |
32119. | 06nov2019 21:20:09 2019m11 50 |
32124. | 06nov2019 21:17:03 2019m11 50 |
33568. | 02nov2019 18:50:30 2019m11 50 |
|---------------------------------------|
34503. | 31oct2019 13:33:42 2019m10 50 |
35094. | 30oct2019 01:00:31 2019m10 50 |
35277. | 29oct2019 14:40:43 2019m10 50 |
36074. | 27oct2019 14:50:15 2019m10 50 |
37511. | 23oct2019 23:06:06 2019m10 50 |
37990. | 22oct2019 21:14:32 2019m10 50 |
38013. | 22oct2019 20:44:16 2019m10 50 |
38015. | 22oct2019 20:42:13 2019m10 50 |
39240. | 20oct2019 07:32:46 2019m10 50 |
39341. | 19oct2019 22:48:31 2019m10 50 |
40233. | 18oct2019 02:27:50 2019m10 50 |
41057. | 15oct2019 17:39:38 2019m10 50 |
42329. | 12oct2019 00:08:40 2019m10 50 |
42875. | 10oct2019 12:45:12 2019m10 50 |
42878. | 10oct2019 12:42:06 2019m10 50 |
42879. | 10oct2019 12:38:53 2019m10 50 |
43356. | 09oct2019 01:38:25 2019m10 50 |
43599. | 08oct2019 13:54:46 2019m10 50 |
46166. | 01oct2019 02:10:14 2019m10 50 |
|---------------------------------------|
48027. | 25sep2019 23:29:15 2019m9 50 |
48277. | 25sep2019 09:32:03 2019m9 50 |
49874. | 21sep2019 01:02:04 2019m9 50 |
50398. | 19sep2019 16:10:22 2019m9 50 |
52452. | 13sep2019 12:29:47 2019m9 50 |
52649. | 12sep2019 21:15:34 2019m9 50 |
|---------------------------------------|
57764. | 28aug2019 08:27:47 2019m8 50 |
57791. | 28aug2019 06:53:20 2019m8 50 |
59213. | 23aug2019 13:42:35 2019m8 50 |
64563. | 06aug2019 13:08:33 2019m8 50 |
65531. | 02aug2019 19:55:02 2019m8 50 |
|---------------------------------------|
66458. | 31jul2019 03:33:16 2019m7 50 |
67163. | 29jul2019 05:48:54 2019m7 50 |
67819. | 27jul2019 08:39:54 2019m7 50 |
69149. | 23jul2019 14:14:28 2019m7 50 |
70898. | 18jul2019 20:53:05 2019m7 50 |
73451. | 11jul2019 14:46:52 2019m7 50 |
74257. | 09jul2019 13:55:01 2019m7 50 |
74346. | 09jul2019 07:58:37 2019m7 50 |
75955. | 04jul2019 06:36:47 2019m7 50 |
|---------------------------------------|
78687. | 26jun2019 17:07:02 2019m6 50 |
78744. | 26jun2019 13:30:53 2019m6 50 |
79523. | 24jun2019 22:09:01 2019m6 50 |
79778. | 24jun2019 00:32:08 2019m6 50 |
82529. | 16jun2019 22:16:27 2019m6 50 |
82636. | 16jun2019 17:58:44 2019m6 50 |
84216. | 12jun2019 20:32:22 2019m6 50 |
84217. | 12jun2019 20:30:56 2019m6 50 |
84941. | 11jun2019 12:40:21 2019m6 50 |
87169. | 05jun2019 02:41:20 2019m6 50 |
88080. | 02jun2019 13:44:31 2019m6 50 |
|---------------------------------------|
95755. | 14may2019 20:12:19 2019m5 50 |
95767. | 14may2019 19:52:46 2019m5 50 |
95768. | 14may2019 19:50:36 2019m5 50 |
95778. | 14may2019 19:37:20 2019m5 50 |
95783. | 14may2019 19:14:10 2019m5 50 |
96975. | 11may2019 20:25:42 2019m5 50 |
98401. | 08may2019 18:50:06 2019m5 50 |
99444. | 06may2019 06:13:25 2019m5 50 |
99693. | 05may2019 14:39:17 2019m5 50 |
99833. | 05may2019 00:28:06 2019m5 50 |
|---------------------------------------|
101814. | 29apr2019 16:04:58 2019m4 50 |
102484. | 27apr2019 13:07:10 2019m4 50 |
102999. | 26apr2019 04:00:06 2019m4 50 |
105012. | 20apr2019 08:40:42 2019m4 50 |
105476. | 19apr2019 03:18:43 2019m4 50 |
109931. | 08apr2019 07:00:24 2019m4 50 |
110004. | 07apr2019 23:58:43 2019m4 50 |
110138. | 07apr2019 15:25:42 2019m4 50 |
110148. | 07apr2019 15:09:39 2019m4 50 |
110974. | 04apr2019 16:59:11 2019m4 50 |
112084. | 02apr2019 01:03:58 2019m4 50 |
112153. | 01apr2019 21:24:24 2019m4 50 |
|---------------------------------------|
113500. | 29mar2019 17:56:37 2019m3 50 |
113546. | 29mar2019 15:55:03 2019m3 50 |
114049. | 28mar2019 15:49:12 2019m3 50 |
114417. | 28mar2019 00:10:27 2019m3 50 |
114419. | 28mar2019 00:08:16 2019m3 50 |
114619. | 27mar2019 12:54:35 2019m3 50 |
114622. | 27mar2019 12:32:26 2019m3 50 |
115910. | 23mar2019 18:11:58 2019m3 50 |
118920. | 15mar2019 08:14:56 2019m3 50 |
119627. | 13mar2019 14:28:10 2019m3 50 |
120255. | 11mar2019 19:40:31 2019m3 50 |
120705. | 10mar2019 17:27:16 2019m3 50 |
120991. | 09mar2019 19:31:36 2019m3 50 |
121604. | 08mar2019 06:32:55 2019m3 50 |
122335. | 06mar2019 11:26:49 2019m3 50 |
123198. | 04mar2019 09:16:06 2019m3 50 |
123611. | 02mar2019 16:10:40 2019m3 50 |
123963. | 01mar2019 10:31:21 2019m3 50 |
|---------------------------------------|
124648. | 27feb2019 10:34:27 2019m2 50 |
125194. | 26feb2019 00:07:48 2019m2 50 |
125213. | 25feb2019 23:11:27 2019m2 50 |
126556. | 21feb2019 21:22:20 2019m2 50 |
132335. | 05feb2019 21:12:33 2019m2 50 |
132336. | 05feb2019 21:11:52 2019m2 50 |
|---------------------------------------|
135055. | 29jan2019 21:21:03 2019m1 50 |
140655. | 15jan2019 14:53:57 2019m1 50 |
141011. | 14jan2019 20:49:19 2019m1 50 |
141765. | 13jan2019 02:26:28 2019m1 50 |
141830. | 12jan2019 20:18:58 2019m1 50 |
142185. | 11jan2019 22:45:06 2019m1 50 |
143105. | 10jan2019 03:41:10 2019m1 50 |
143447. | 09jan2019 08:01:42 2019m1 50 |
144788. | 05jan2019 21:39:49 2019m1 50 |
144789. | 05jan2019 21:37:17 2019m1 50 |
144944. | 05jan2019 15:19:23 2019m1 50 |
145903. | 02jan2019 17:53:20 2019m1 50 |
+---------------------------------------+
With the same formula above, but dropping theymos from the dataset, we have the 50-merit transaction group is ranked at 5 th position, with 2.2% of total merit values (significantly decreased from 3.1% with full dataset). +--------------------------------------------------------------------------------------+
| merit_cat total total_cat p_meritcat total_count meritcat_count p_count |
|--------------------------------------------------------------------------------------|
1. | 1 254141 101257 39.8 143993 101257 70.3 |
2. | 3 - 9 254141 77630 30.5 143993 18382 12.8 |
3. | 2 254141 44682 17.6 143993 22341 15.5 |
4. | 10 254141 12740 5 143993 1274 .9 |
5. | 50 254141 5650 2.2 143993 113 .1 |
|--------------------------------------------------------------------------------------|
6. | 11 - 19 254141 4262 1.7 143993 297 .2 |
7. | 20 254141 2660 1 143993 133 .1 |
8. | 31 - 49 254141 2047 .8 143993 52 0 |
9. | 25 254141 1100 .4 143993 44 0 |
10. | 30 254141 840 .3 143993 28 0 |
|--------------------------------------------------------------------------------------|
11. | 21 - 24 254141 688 .3 143993 31 0 |
12. | 26 - 29 254141 689 .3 143993 25 0 |
13. | <0 254141 -104 0 143993 16 0 |
+--------------------------------------------------------------------------------------+
Additional details, see: https://bitcointalk.org/index.php?topic=5215884.msg53557181#msg53557181
|
|
|
|
As for now, there is a limit on total amount of merit one can send to another one each 30 days: 50 merits per one user per each 30 days. For the suggestion to limit total amount of merits that one post is allowed to receive, it is unfair, and unlogical in my opinion. The forum has more than 2 millions of users so why the forum should have a rule on "First come, first meriters". Everyone have rights to merit the others. Do you think that these threads deserve only 50 merits? |
|
|
|
But this time, it is for ranks Do you mean for only DT1 and DT2 users, or for all users? The former is easy to do, the latter will have outdated information because 2.7 million profiles aren't instantly updated on BPIP. Initially, I thought of ranks for all users because I thought BPIP has such data despite of the fact BPIP does not instantly update it, especially recent months. From your comments, it raises one thing that you can dump such data easily. I have the idea like that: "What if we can observe data on DT 1/2 members over months and see how long as well as how consistent they maintain their positions as DT1/2 members. I know with the algorithm to automatically include and exclude DT members each month from theymos, it seems to be difficult that someone can maintain DT member positions for many months. theymos updates his trust list each month so if you can, please dump that data monthly. |
|
|
|
|
Show Posts
