I think that grin-tech.org is just down right now. Nevermind, fixed. Thanks. Kinda dissapointed that Howeycoins can't achieve the same thing despite being older.
Since everyone who invested in howeycoins became a billionaire, I was worried about what would happen to the world economy if I promoted it even more.
|
|
|
November 2021 update: grin payments are currently not being accepted. My payments code broke, and since grin payments were never very common, it hasn't been a priority to fix it. I'm super excited about grin. All past altcoins have been just Bitcoin with a few bits tacked on; occasionally these extra bits are useful/interesting (eg. Monero or Ethereum), but in the vast majority of cases this extra stuff is just meaningless marketing-oriented garbage. But grin is packed full of useful innovation from top to bottom; moreover, it's clearly built in the same cypherpunk spirit that Bitcoin was: increased freedom/sovereignty through technology. Therefore, I'm happy to announce that the forum is now accepting grin payments automatically, probably the first site other than exchanges to do so. You'll find a link at the bottom of the evil-fee and copper-membership pages. grin is new and clunky to use. I don't expect many people to use it, honestly. But I needed to rewrite the forum payments system anyway in order to support LN in the future and to fix some longstanding issues with the old code, so adding grin support worked out nicely. I don't recommend buying or not buying grin. Due to its emission schedule, I'd guess that its price will have a general downward trend for quite some time, but who knows. Currently I own zero grin (though I will be buying from the forum all grin obtained), I was not paid to add grin support, and in fact not a soul knew that I was going to do so. grin support might be removed later if it dies off or becomes too time-consuming for me to maintain. I tested this with grin's floonet (testnet), but not mainnet yet since I don't have any grin. Hopefully it works.
A few observations I had while implementing this: By default they want you to essentially pay to IP addresses. This was stupid when Satoshi tried it 10 years ago, and it's stupid now. At the very least you should strongly encourage (ie. nearly force) people to give out public keys along with their IPs, since otherwise MITM attacks are trivial. Even then it sucks to require the recipient to run an open-to-the-Internet server at all. And for goodness' sake, don't use the broken/centralized HTTPS system; the Bitcoin Core devs have been going to a lot of trouble trying to remove that garbage from Core. A better protocol for the copy/paste method is needed. For one, you shouldn't have to use intermediary files. I was annoyed when I did grin wallet send -m file -d - and it actually created a file called "-" instead of writing to stdout like it should. grin needs to be much better at handling transactions that never continue beyond the first or second step in the three-way transaction process. They probably shouldn't even show up in the main transaction log. Currently I think that there's no way for the recipient to get the modified slate after running receive the first time (eg. if it gets lost), which is nuts. And currently there appears to be no reasonable method for proving that you sent a transaction.
|
|
|
I'm not a huge fan of the fixed subsidy, but it is deflationary long-term. Because the subsidy remains the same while the money supply grows (and may shrink due to lost coins), a graph of the inflation rate over time is steadily downward, and will eventually reach low levels. However, since their stated reason for doing this was to ensure that miners are properly incentivized, it would've made more sense to set the subsidy such that the monetary inflation rate is a constant 0.5% or something. As they've designed it, the inflation rate will start out way too high, and then if grin survives for a very long time, it'll eventually become too low to actually meet their goal of incentivizing miners. Inflation will ensure a general downward price trend for at least the first year, I'd expect, and it becomes sort-of reasonable only after 4 years. Will grin survive that long? Not sure. If you think it will, then it might make sense to buy grin at very cheap prices in its first few years, and this thinking could perhaps stabilize the market somewhat. Grin inflation ratesYear # | Yearly monetary inflation rate | 1 | 36500% | 2 | 100% | 3 | 50% | 4 | 33% | 5 | 25% | 6 | 20% | 7 | 17% | 8 | 14% | 11 | 10% | 21 | 5% | 34 | 3% |
It's possible that people will get just too fed up with the inflation in the first few years, and everyone will move to a clone, similar to the Bytecoin->Monero switch. Beam is too much of an obvious cheap money-grab to succeed IMO, though. In addition to the money supply issue, grin is a worse store of value than Bitcoin because: - The dev culture is built upon a more flexible idea of system consensus. There are expected to be regular hardforks. - The crypto is experimental, and the currency is far newer. - Smart contracts are more limited, though at this time I'm not exactly sure how much more limited. A BTC-backed grin clone could be a Bitcoin sidechain, but you won't see this anytime soon. First of all, there sadly hasn't been that much work on Bitcoin sidechains. Also, although you can do a semi-centralized sidechain without any consensus work or widespread costs, a full-security sidechain involves a softfork which would require all Bitcoin full nodes to also be grin-sidechain full nodes, increasing full node costs. I'd guess that if it happens at all, it won't be for 3-5 years, after grin has proven itself. At that point grin could have a significant first-to-market advantage, and its inflation will be reaching reasonable levels. Unlike the vast majority of other altcoins, grin was basically built in the same spirit as Bitcoin - the same ideology. I'm a "Bitcoin maximalist" because I believe in "the Bitcoin idea/ideology", not as part of some game theoretic strategy to make BTC's price go up. If Bitcoin is out-competed in all respects (which grin is very far from doing, and other altcoins aren't even in contention for), then it'd be good for Bitcoin to be replaced by that competitor. IMO in 10 years: - 30% chance grin is defunct, but roughly the same basic features are provided by other BTC-based off-chain systems such as LN. - 25% chance grin is defunct, but basically the same thing exists as a widely-used Bitcoin sidechain. - 15% chance BTC is the main store of value in crypto, while grin or a very similar altcoin is used for most daily payments. - 1% chance grin advances significantly, and combined with its first-to-market advantage vis-á-vis its innovations, it out-competes BTC entirely. - 14% chance some other altcoin out-competes BTC entirely. It won't be one of the existing ones, except perhaps grin as mentioned above. - 15% chance global authoritarianism makes it very difficult to use cryptocurrencies at all, and the whole sector is reduced to a tiny niche.
|
|
|
Has anything been written anywhere about the reasons for this? I can't imagine it's a money making measure. I also can't imagine it's going to deter the people who aren't already deterred by it.
It's just that I last changed the price when the BTC/USD price was $12k, so it's drifted from the intended value. Evil fees will also be updated. The price will be fixed in bitcoins so imagine what will happen when we enter a bull market again.
Then I'll (eventually) adjust it downward again. I like to keep the BTC-denominated price pretty stable and not change it every time the market freaks out in either direction, but it's supposed to have a vaguely consistent real value.
|
|
|
Are you guys EXCITED????
So if there are no addresses and exchanges of Grin are 'person to person' so to speak, then if I mine on a pool using windows miner, how would I be rewarded for mining ? Is it by IP, email ? I don't have a Linux instance currently to view the wallet.
I don't know how it works with mining specifically, but in general: grin payments require a three-way process. This can be done automatically through an IP address or keybase, or you can do it manually like this: 1. The sender runs grin wallet send -m file -d FILE.txt GRIN_AMOUNT, which creates the file FILE.txt. 2. The sender gives FILE.txt to the recipient. 3. The recipient runs grin wallet receive -i FILE.txt, which creates another file FILE.txt.response. 4. The recipient gives FILE.txt.response to the sender. 5. The sender runs grin wallet finalize -i FILE.txt.response, and the transaction is done. The IP/keybase methods do these same steps, just automatically.
I'm not going to be mining, but I would like to buy some grin ASAP on the first day. If anyone here is lucky enough to quickly mine some, I'll pay $13/grin (in BTC), but only for the first few grin I buy. PM me.
|
|
|
I've thought about it before as a poll option, and I think that it would be useful, but implementing it has never approached the top of my to-do list.
|
|
|
Am I understanding the 'random subset of 100 users' statement correctly?... that we will ultimately end up with a DT1 list of 100, before exclusions, when more people fall into the criteria?
Once there's more than 100 users who would be selected to DT1, a random subset of those eligible will be selected each month. Or that's my current thinking, at least. This will help prevent people from being unfairly attacked by even a majority of DT1, since some month you might lose the dice roll and find yourself in the minority for a while. As I mentioned in the OP, it creates more of a credible threat of retaliation, which I believe will have a moderating effect overall. It's a good thing that there are way more DT members. This incentivizes users to properly develop their own trust list rather than stumbling on a path of lunacy as we have scores of users sloshing about the feedback sewers. Beyond that, the value of DT has been diluted immensely and thus reliance upon it as a proper vector for trust isn't the most brilliant idea.
Yes, that's my intention. Once someone thinks, "DT is basically OK, but it's a bit chaotic, and every now and then I see something that I disagree with," then they've graduated from trust-newbie and are ready to build their own list. The old system was too safe/static/universal/untouchable. (But I don't want DT to be absolute garbage, either, since trust-newbies need some guidance.)
|
|
|
M (number of V vertices) is not given right?
M is the number of vertices in the input graph, and is known. The number that should be in the optimal output is not known. Typo on your end in the 2nd optimal solution? I figure you meant either v1 or v3 for one of those vectors?
Right, thanks.
|
|
|
DT1 has been reconstructed with all of the criteria. Old: achow101 actmyname BitcoinPenny Blazed Cyrus dooglus gmaxwell greenplastic HostFat JohnUser krogothmanhattan Lauda Mitchell monkeynuts OgNasty owlcatz qwk SebastianJu suchmoon The Pharmacist theymos TMAN zazarb
New: achow101 actmyname asche BitcoinPenny Blazed coinlocket$ Coolcryptovator cryptodevil Cyrus DarkStar_ dooglus EcuaMobi gmaxwell greenplastic Halab Hhampuz hilariousandco iasenko ibminer ICOEthics Jet Cash JohnUser krogothmanhattan Lafu Lauda Lesbian Cow LoyceV marlboroza minerjones Mitchell monkeynuts mprep OgNasty owlcatz qwk SebastianJu suchmoon TheFuzzStone The Pharmacist theymos TMAN tmfp TookDk vizique Vod Welsh xtraelv yahoo62278 yogg zazarb I plan to do it again early every month from now on, with adjustments as needed. But if we assume that this general system continues forever, the long-term goal is to keep the critera basically stable and then let the list actually grow over time: the goal is not to constantly select the "top 50 forum users" or similar, but to select a wide swath of users who are basically acceptable.
|
|
|
Here's how the voting would work if it were performed right now. The first one comes after all of the other criteria, and is then fed into the second. yxt via: phantastisch twbt Dunkelheit667 lassdas Chefin qwk fronti o_solo_miner meph SebastianJu xtraelv via: DdmrDdmr taikuri13 iasenko marlboroza ICOEthics 1miau Lafu qwk tmfp cryptodevil Jet Cash via: joniboini The Pharmacist Vod iasenko TMAN mdayonliner bL4nkcode NeuroticFish CryptopreneurBrainboss vizique tmfp via: suchmoon ibminer marlboroza DarkStar_ ICOEthics Coolcryptovator cryptodevil bL4nkcode owlcatz IconFirm Halab via: theymos kenzawak JohnUser TomCrypto F2b Saint-loup asche Lafu Foxpup yogg EcuaMobi via: suchmoon d5000 DarkStar_ Quickseller sandy-is-fine minifrij MadZ tmfp owlcatz KWH ezeminer via: minerjones TMAN BitcoinPenny anonymousminer 2stout hedgy73 dazedfool BG4 greenplastic TookDk Welsh via: DdmrDdmr Jet Cash Alex_Sr DooMAD iasenko Coolcryptovator Lafu mdayonliner CryptopreneurBrainboss rockmoney TookDk via: philipma1957 OgNasty minerjones qwk Lesbian Cow BitcoinPenny ezeminer hephaist0s hedgy73 Anduck Coolcryptovator via: Theb coinlocket$ lovesmayfamilis ICOEthics Lafu qwk SFR10 bones261 S_Therapist tmfp asche via: mole0815 TomCrypto JohnUser cestmoi DarkStar_ Saint-loup Tramirostronix Lafu 1miau qwk cryptodevil via: LoyceV suchmoon xtraelv dooglus DarkStar_ marlboroza Coolcryptovator willi9974 bones261 tmfp mprep via: LoyceV Welsh OgNasty hilariousandco Lafu eddie13 qwk sapta mdayonliner cabalism13 yogg via: TomCrypto krogothmanhattan Saint-loup minerjones TMAN asche Coolcryptovator Kryptowerk anonymousminer Xprim777 vizique via: batesresearch TMAN Mitchell Lesbian Cow yogg BitcoinPenny anonymousminer Ticked BitcoinNewsMagazine owlcatz zazarb via: krishnapramod Quickseller yahoo62278 Timelord2067 Naster Fakhoury mdayonliner BitcoinPenny paramind22 exstasie Lafu via: mole0815 Vod xtraelv VonSpass aundroid iasenko Buchi-88 asche Coolcryptovator 1miau ICOEthics via: mole0815 kenzawak coinlocket$ xtraelv lovesmayfamilis F2b DarkStar_ marlboroza Coolcryptovator nutildah JohnUser via: Becassine Aerys2 Saint-loup Shitcointalk cestmoi F2b Tramirostronix DarkStar_ Lauda asche SebastianJu via: phantastisch OgNasty Chefin eneloop Dabs qwk dogie itod Blazed NeuroticFish yahoo62278 via: Direwolve735 coinlocket$ o_e_l_e_o The Pharmacist Steamtyme marlboroza qwk Kate Beckett examplens mdayonliner coinlocket$ via: Piggy mole0815 duesoldi LoyceV Micio Makkara JohnUser babo DarkStar_ asche Lesbian Cow via: krogothmanhattan minerjones bill gator Mitchell teeGUMES TECSHARE yogg BitcoinPenny anonymousminer Ticked monkeynuts via: krogothmanhattan minerjones Lauda TMAN Hhampuz qwk TheNewAnon135246 TECSHARE yogg BitcoinPenny ibminer via: theymos suchmoon Vod The Pharmacist Lauda marlboroza TryNinja BitCryptex TMAN Quickseller BitcoinPenny via: zazarb Flying Hellfish minerjones bill gator Kryptowerk Lesbian Cow TheNewAnon135246 teeGUMES yogg anonymousminer achow101 via: zazarb ETFbitcoin joniboini DooMAD RGBKey DarkStar_ HCP TryNinja Quickseller TMAN greenplastic via: krogothmanhattan OgNasty ChiBitCTy bill gator Hhampuz qwk Kryptowerk Lesbian Cow Hiroaki TheNewAnon135246 owlcatz via: Lutpin romanornr krogothmanhattan suchmoon The Pharmacist xtraelv minerjones TMAN TheFuzzStone qwk TMAN via: Jet Cash krogothmanhattan suchmoon The Pharmacist Vod Alex_Sr Lauda amishmanish stompix nutildah krogothmanhattan via: kenzawak frankbitcoin OgNasty d5000 iasenko bill gator TMAN qwk eddie13 Kryptowerk actmyname via: LoyceV suchmoon The Pharmacist o_e_l_e_o minerjones DarkStar_ iasenko HCP Lauda hilariousandco marlboroza via: LoyceV suchmoon The Pharmacist o_e_l_e_o taikuri13 xtraelv HCP iasenko hilariousandco Lauda Cyrus via: theymos LoyceV achow101 EFS OgNasty iasenko ICOEthics Quickseller Veleor eddie13 DarkStar_ via: kenzawak LoyceV TheQuin suchmoon o_e_l_e_o The Pharmacist DooMAD Steamtyme iasenko HCP Hhampuz via: SaltySpitoon Flying Hellfish krogothmanhattan minerjones ChiBitCTy Lauda marlboroza bill gator TMAN qwk dooglus via: theymos LoyceV achow101 suchmoon mprep Vod OgNasty RGBKey xtraelv RHavar qwk via: mithrim mole0815 The Pharmacist xtraelv phantastisch Toxic2040 aundroid Abdussamad twbt ibminer Mitchell via: Lutpin achow101 krogothmanhattan The Pharmacist RHavar hilariousandco Lauda EcuaMobi TMAN TryNinja gmaxwell via: theymos nullius achow101 ETFbitcoin LoyceV The Pharmacist joniboini OgNasty xtraelv Welsh OgNasty via: theymos SaltySpitoon krogothmanhattan HagssFIN PolyPanto Vod cryptohunter TheFuzzStone bill gator mikeywith minerjones via: joniboini Steamtyme TMAN bill gator Hhampuz Xprim777 Ticked qwk yahoo62278 actmyname Blazed via: LoyceV The Pharmacist EcuaMobi suchmoon minerjones d5000 Toxic2040 TMAN Lauda Tomatocage The Pharmacist via: LoyceV suchmoon Jet Cash xtraelv o_e_l_e_o Vod coinlocket$ Toxic2040 TMAN Lauda LoyceV via: micgoossens DdmrDdmr TheQuin Jet Cash suchmoon OgNasty o_e_l_e_o coinlocket$ DooMAD Vod Lauda via: gmaxwell suchmoon minerjones The Pharmacist Limx Dev Vod hilariousandco Aerys2 scutzi128 Coolcryptovator suchmoon via: DdmrDdmr mole0815 Last of the V8s hilariousandco The Pharmacist Flying Hellfish Coolcryptovator bill gator Vod o_e_l_e_o Vod via: LoyceV Last of the V8s suchmoon The Pharmacist Jet Cash o_e_l_e_o TMAN Lauda asche xtraelv hilariousandco via: theymos LoyceV The Pharmacist suchmoon Jet Cash Lauda TMAN marlboroza Hhampuz o_e_l_e_o theymos via: DdmrDdmr Last of the V8s o_e_l_e_o achow101 Vod xtraelv joniboini krogothmanhattan iasenko coinlocket$ SebastianJu via: OgNasty qwk ezeminer via: minerjones TMAN zazarb via: yahoo62278 mdayonliner EcuaMobi via: suchmoon d5000 Lesbian Cow via: krogothmanhattan bill gator TookDk via: philipma1957 OgNasty BitcoinPenny via: zazarb Flying Hellfish yogg via: krogothmanhattan asche asche via: mole0815 DarkStar_ Coolcryptovator via: coinlocket$ ICOEthics Halab via: theymos kenzawak greenplastic via: Hhampuz krogothmanhattan monkeynuts via: Lauda Hhampuz JohnUser via: Lafu DarkStar_ Jet Cash via: joniboini The Pharmacist tmfp via: suchmoon ibminer yahoo62278 via: o_e_l_e_o The Pharmacist Welsh via: DdmrDdmr Jet Cash cryptodevil via: LoyceV xtraelv xtraelv via: DdmrDdmr taikuri13 mprep via: LoyceV Welsh Lafu via: Vod mole0815 Cyrus via: theymos achow101 krogothmanhattan via: iasenko eddie13 ICOEthics via: coinlocket$ xtraelv owlcatz via: Lutpin romanornr minerjones via: joniboini Steamtyme coinlocket$ via: Piggy LoyceV TMAN via: Jet Cash suchmoon OgNasty via: theymos HagssFIN achow101 via: ETFbitcoin HCP ibminer via: theymos Vod Hhampuz via: SaltySpitoon marlboroza dooglus via: theymos achow101 Mitchell via: Lutpin achow101 Blazed via: LoyceV The Pharmacist qwk via: Toxic2040 The Pharmacist marlboroza via: Veleor LoyceV actmyname via: suchmoon o_e_l_e_o Lauda via: gmaxwell Limx Dev DarkStar_ via: TheQuin hilariousandco gmaxwell via: theymos nullius The Pharmacist via: LoyceV BitCryptex Vod via: Last of the V8s QuestionAuthority hilariousandco via: theymos Jet Cash suchmoon via: Last of the V8s DdmrDdmr LoyceV via: micgoossens DdmrDdmr theymos via: DdmrDdmr Last of the V8s
|
|
|
I have 214 earned merits. Let's assume I have included 30 persons in my trust list. How will system choose my vote, I mean by which criteria, since I have capability of voting for 21 member. How someone from my 30 members will be excluded/included?
Right now only 1 person in your trust list is eligible at that point in the DT1 generation process (namely Coolcryptovator), so it doesn't matter. In the vast majority of cases, it's like this, where there is no contention at all. If there is contention, then the system tries to distribute the votes such that the greatest number of people would be included in DT1 at the end. If there's still contention (or if my algorithm behaves sub-optimally), then it's chosen randomly among the remaining options. But this is a bit rare: if DT1 was constructed now, no randomness would be involved, since all contention would be resolvable without it. I think it will be choosen by either the members trust score or whom most of the people have included. For example, if someone has 20 earned merits and includes 3 member in trust list, system will check among those 3 member who has been included by most others person. Assume, I have 20 earned merit and included A, B, C in my trust list. Anyone from this 3 will be excluded by- Assume- A- trusted by 20 members B- trusted by 11 members C- trusted by 15 members. Then my vote will go for A and C, B will be excluded. Is that correct, can someone confirm?
In that case your vote doesn't matter, since they're all above 10. If it was instead: A- trusted by 20 B- trusted by 9 C- trusted by 9 Then your votes would go to B and C, since that would result in the greatest number of people in DT1.
|
|
|
I might help out and spend a day thinking about it but the explanation from the graph is a bit confusing.
Can you dumb it down even further? Just a short description of what are the inputs exactly, and how do you want the output. Better if it's just an example with 5 users or something.
G = (U, V, E) is a bipartite graph with edges from the left side, U, to the right side, V. There are N vertices in U and M vertices in V. A "capacity" function c: U -> Z is defined for every vertex in U. A constant integer "target value" T exists. Candidate solutions are subgraphs S = (US, VS, ES) of G satisfing the following requirements: 1. For each vertex u in US, the number of edges attached to u must be less than or equal to c(u). 2. For each vertex v in VS, the number of edges attached to v must be greater than or equal to T. Find an S such that the number of vertices in VS is maximal. Example: Note that this graph is depicted as directed, but that doesn't actually matter. Note: - To satisfy requirement #1, you must exclude at least two of (u1, v1) or (u1, v3) or (u1, v4). - To satisfy requirement #1, you must exclude at least one of (u2, v1) or (u2, v2). - To satisfy requirement #1, you must exclude at least one of (u3, v1), (u3, v2) or (u3, v3) - To satisfy requirement #2, you must exclude at least v4 (since it cannot possibly get T=2 edges), and possibly more depending on the rest of S. In a very naïve greedy algorithm, you might just fill up vertices on the right from top to bottom until you can't do anything else. That'd give a candidate solution of: (u1, v1) (u2, v1) This is a valid candidate solution, but it's non-optimal because it includes only 1 vertex in V whereas 2 are possible. In order to achieve an optimal solution, you need some backtracking, at least. In this case there are two equally-good optimal solutions: (u1, v3) (u3, v3) (u2, v2) (u3, v2) or: (u1, v1) (u3, v1) (u2, v2) (u3, v2) It becomes more complicated as the graph gets bigger. Writing it down in this way reminds me a lot of the stable marriage problem, which gives me hope that it can be solved exactly.
|
|
|
So for example, someone with 518 earned merits would get up to 2 votes in the 250-merit criteria and up to 51 votes in the 10-merit criteria, if I'm getting this right.
Someone with 72 earned merits gets up to 7 votes in the 10-merit criteria and obviously none in the 250.
Right. Also, for these calculations you're not counted as trusting someone if the merit they've given you puts you below the 10- or 250-merit threshold. The 250-merit thing happens at the very end (after the 10-merit one) when there are only about 50 people in consideration (currently), so 2 votes is not insubstantial there, and you're not that likely to actually be limited. I assume both can be used in full, i.e. using the 250-votes doesn't reduce the number of available 10-votes (or maybe I should call them "ballots" to not confuse with the person getting the votes). Right.
|
|
|
Each user's number of "votes" in the last two criteria will be limited to floor(earned_merit / (10 or 250, depending on the criteria)). If you trust more people than your limit, then you will vote for the people to whom your vote will be the most useful, more-or-less. I wasn't able to find either an optimal or low-error-approximate solution to this problem. My current algorithm is sub-optimal in general and could produce results uncomfortably far from the optimal solution, but the current data doesn't actually present a scenario where it matters: my current algorithm is optimal with the current data. Long-term, if I can't find an algorithm that I'm happy with, I could make the trust lists ordered as some have suggested. When building your trust list, I tend to encourage people not to worry about little details like this, and instead just think about the system in broad strokes. If this results in poor outcomes, then that's a problem on my end. And I want to insist on my suggestion regarding trust: guest should see some trust.
The main reason that I went for this solution rather than forcing custom lists is that I would like to show some trust indicator to guests. But before doing that, I want to see whether these modifications can actually be made to work. If not, then I may go to the force-custom-lists solution, and that's incompatible with guests seeing any trust indicators.
|
|
|
If you're just accepting and issuing payments from the forum, you should only require a small number of private channels (~5, depending on the size of payments and how well-balanced the flows are) to gateway routing nodes. Routing nodes basically are the third-parties that "trustlessly proxy incoming LN payments" (and outgoing). Some more info about this can be found in this blog post: https://blog.lightning.engineering/posts/2018/05/30/routing.html. There's really no reason for the forum to be doing routing, as each of the forum members should be creating channels to routing nodes as well (so that they can send and receive payments to and from anyone in the network), not just the forum node itself. As far as DDoS protection, that's definitely not my area of expertise, but in the standard case, an LN node can filter traffic from IP addresses other than the ~5 routing nodes you have, and can also filter anything outside of a specific set of ports. Also, since you would be using private channels, the IP address of your node won't be visible to anyone other than your set of routing nodes, and you can also use Tor if you'd like to keep it private from them as well. I didn't know that, thanks. I'll try to figure it out when I get time. It would be nice for this all to be handled automatically, though. What LN software were you trying to use?
I was looking mainly at c-lightning because I don't want to use btcd and c-lightning's documentation seemed better-organized, but it looks like lnd might be better. (Also, after looking more closely, it might be possible to run lnd without btcd.)
|
|
|
The forum sells ad space in the area beneath the first post of every topic page. This income is used primarily to cover hosting costs and to pay moderators for their work (there are many moderators, so each moderator gets only a small amount -- moderators should be seen as volunteers, not employees). Any leftover amount is typically either saved for future expenses or otherwise reinvested into the forum or the ecosystem. Ads are allowed to contain any non-annoying HTML/CSS style. No images, JavaScript, or animation. Ads must appear 3 or fewer lines tall in my browser (Firefox, 900px wide). Ad text may not contain lies, misrepresentation, or inappropriate language. Ads may not link directly to any NSFW page. No ICOs [1], banks, funds, or anything else that a person can be said to "invest" in; I may very rarely make exceptions if you convince me that you are ultra legit, but don't count on it. Ads may be rejected for other reasons, and I may remove ads even after they are accepted. There are 10 total ad slots which are randomly rotated. So one ad slot has a one in ten chance of appearing. Nine of the slots are for sale here. Ads appear only on topic pages with more than one post, and only for people using the default theme. Duration- Your ads are guaranteed to be up for at least 7 days. - I usually try to keep ads up for no more than 8 or 9 days. - Sometimes ads might be up for longer, but hopefully no longer than 12 days. Even if past rounds sometimes lasted for long periods of time, you should not rely on this for your ads. StatsExact historical impression counts per slot: https://bitcointalk.org/adrotate.php?adstatsInfo about the current ad slots: https://bitcointalk.org/adrotate.php?adinfoAd blockingHero/Legendary members, Donators, VIPs, and moderators have the ability to disable ads. I don't expect many people to use this option. These people don't increase the impression stats for your ads. I try to bypass Adblock Plus filters as much as possible, though this is not guaranteed. It is difficult or impossible for ABP filters to block the ad space itself without blocking posts. However, filters can match against the URLs in your links, your CSS classes and style attributes, and the HTML structure of your ads. To prevent matches against URLs: I have some JavaScript which fixes links blocked by ABP. You must tell me if you want this for your ads. When someone with ABP and JavaScript enabled views your ads, your links are changed to a special randomized bitcointalk.org URL which redirects to your site when visited. People without ABP are unaffected, even if they don't have JavaScript enabled. The downsides are: - ABP users will see the redirection link when they hover over the link, even if they disable ABP for the forum. - Getting referral stats might become even more difficult. - Some users might get a warning when redirecting from https to http. To prevent matching on CSS classes/styles: Don't use inline CSS. I can give your ad a CSS class that is randomized on each pageload, but you must request this. To prevent matching against your HTML structure: Use only one <a> and no other tags if possible. If your ads get blocked because of matching done on something inside of your ad, you are responsible for noticing this and giving me new ad HTML. Designing adsMake sure that your ads look good when you download and edit this test page: https://bitcointalk.org/ad_test.htmlAlso read the comments in that file. Images are not allowed no matter how they are created (CSS, SVG, or data URI). Occasionally I will make an exception for small logos and such, but you must get pre-approval from me first. The maximum size of any one ad is 51200 bytes. I will send you more detailed styling rules if you win slots in this auction (or upon request). Auction rulesYou must be at least a Jr Member to bid. If you are not a Jr Member and you really want to bid, you should PM me first. Tell me in the PM what you're going to advertise. You might be required to pay some amount in advance. Everyone else: Please quickly PM newbies who try to bid here to warn them against impersonation scammers. If you have never purchased forum ad space before, and it is not blatantly obvious what you're going to advertise, say what you're going to advertise in your first bid, or tell me in a PM.Post your bids in this thread. Prices must be stated in BTC per slot. You must state the maximum number of slots you want. When the auction ends, the highest bidders will have their slots filled until all nine slots are filled. So if someone bids for 9 slots @ 5 BTC and this is the highest bid, then he'll get all 9 slots. If the two highest bids are 9 slots @ 4 BTC and 1 slot @ 5 BTC, then the first person will get 8 slots and the second person will get 1 slot. The notation "2 @ 5" means 2 slots for 5 BTC each. Not 2 slots for 5 BTC total.- When you post a bid, the bids in your previous posts are considered to be automatically canceled. You can put multiple bids in one post, however. - All bid prices must be evenly divisible by 0.02. - The bidding starts at 0.02. - I will end the auction at an arbitrary time. Unless I say otherwise, I typically try to end auctions within a few days of 10 days from the time of this post, but unexpected circumstances may sometimes force me to end the auction anytime between 4 and 22 days from the start. I have a small bias toward ending auctions on Fridays, Sundays, and Mondays. - If two people bid at the same price, the person who bid first will have his slots filled first. - Bids are considered invalid and will be ignored if they do not specify both a price and a max quantity, or if they could not possibly win any slots If these rules are confusing, look at some of the past forum ad auctions to see how it's done. I reserve the right to reject bids, even days after the bid is made. Price flatteningAt the end of the auction, after the winning bids are all determined, I will do a "price flattening" operation. This has no effect on which bids actually win. For each bid, in order of lowest to greatest price/slot, I will reduce each bid's price/slot to the highest value which is equal to or only the minimum increment greater than the next-lower bid. This allows you to bid higher prices without worrying so much, but you still mustn't bid more than you're willing to pay. Example: This: Slots BTC/Slot Person 6 0.20 A 1 0.16 B 1 0.08 C 1 0.08 D
Becomes: Slots BTC/Slot Person 6 0.12 A [step 4: reduced to 0.10+0.02=0.12] 1 0.10 B [step 3: reduced to 0.08+0.02=0.10] 1 0.08 C [step 2: same as the next-lowest, unchanged] 1 0.08 D [step 1: the lowest bid is always unchanged] Payment, etc.You must pay for your slots within 24 hours of receiving the payment address. Otherwise your slots may be sold to someone else, and I might even give you a negative trust rating. I will send you the payment information via forum PM from this account ("theymos", user ID 35) after announcing the auction results in this thread. You might receive false payment information from scammers pretending to be me. They might even have somewhat similar usernames. Be careful. [1]: For the purposes of forum ads, an ICO is any token, altcoin, or other altcoin-like thing which meets any of the following criteria: it is primarily run/backed by a company; it is substantially, fundamentally centralized in either operation or coin distribution; or it is not yet possible for two unprivileged users of the system to send coins directly to each other in a P2P way. The intention here is to allow community efforts to advertise things like Litecoin, but not to allow ICO funding, even when the ICO is disguised in various ways.
|
|
|
Auction ended, final result: Slots BTC/Slot Person 5 0.16 blenderio 4 0.16 lightlord
|
|
|
Crap, I wish I had paid more attention in my CS classes. No recollection of max flow whatsoever. Google is extremely unhelpful. So what's the range for X and how does it depend on merit? Can it be negative? How big is N - that's only users who have custom trust lists, right? I feel like I'm missing something obvious here.
https://en.wikipedia.org/wiki/Max_flowhttps://en.wikipedia.org/wiki/Edmonds%E2%80%93Karp_algorithmNote that you can require a "minimum flow" per edge and still be the same problem, but that refers to requiring that much flow, where 0 is not allowed. My intuition is that with my "0 or 10" requirement, it becomes the (NP-hard) knapsack problem. There are good approximations for that, though.
I was thinking that X = earned_merit intdiv (10 or 250), but I'm not sure. N = all users who match the current truster criteria, either 10 or 250 earned merit. The "excluding merit sent by the trustee" thing couldn't be added here AFAICT, and would have to just limit users allowed into this step. M = the number of distinct users trusted by the users on the left side.
|
|
|
@theymos No comment on this suggestion? I have a nice graph too
It's an interesting idea, but I think that trust ratings and trust lists are fundamentally different concepts which shouldn't be mixed. Just because you had a good trade with someone doesn't mean that you trust their judgement generally. For example, your system would tend to strongly amplify long cons like pirateat40, I think. Also, we're not going to moderate things like "did a trade actually occur, and with x value?".
|
|
|
|