The code is 10 random characters from an alphabet of 62 characters; you're never brute-forcing that over a network. You'd bring down the forum before you got to even 10000 attempts per second. Most likely the email was intercepted at his end somehow.

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.

Stats

Exact historical impression counts per slot:
https://bitcointalk.org/adrotate.php?adstats

Info about the current ad slots:
https://bitcointalk.org/adrotate.php?adinfo

Ad blocking

Hero/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 ads

Make sure that your ads look good when you download and edit this test page:
https://bitcointalk.org/ad_test.html
Also 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 rules

You 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.

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.

Bids must be evenly divisible by 0.02. If they're not, they get rounded down.


We don't do that.


Sorry, you have negative trust from my perspective, so I won't accept your bids.


Sorry, no ICOs.


I still think that this is too ICO-like.

Auction ended, final result:
Slots BTC/Slot Person
1 0.28 bumbaio
1 0.28 Betex
4 0.28 ChipMixer
2 0.24 irfan_pak10
1 0.24 Gunthar

After further investigation, this was in fact a bug. It looks like about 10% of payments made between March 3 and now were not credited. I put a notice at the top of the unproxyban and promote page so that people can email me and I'll sort it out for them.

SaleerBot, I already fixed your balance, just revisit the promote page.

You should assume that all data is available to attackers, at the very least because I am sure that the forum's security is not beyond extra-legal covert groups such as the NSA.

When police (any police, worldwide) contacts me about a forum user engaging in a non-victimless crime (eg. scamming) where I perceive that probable cause exists, I may assist them in their investigation voluntarily.

The forum is under US jurisdiction, so it is impossible to ignore US subpoenas. I try to have the scope of subpoenas narrowed as much as reasonably possible, but it's very expensive/difficult/time-consuming to fight these things. The degree to which I fight them depends on my perception of the costs and benefits, thinking about questions like:

 - Is the alleged crime victimless?
 - Is the person probably guilty?
 - Will the information in question actually change the case much?
 - How strong are the forces behind the subpoena?
 - How much can actually be won? Oftentimes, it is extremely unlikely that I could do more than massively delay the process and improve a few minor issues by fighting the subpoena, even in the best case.

For example, I didn't fight the Ross Ulbricht's subpoena at all because it was extremely narrow already and probably nothing could've been gained even if I had somehow fought it off completely. The BFL subpoena on the other hand originally asked for all PMs that even mentioned BFL, but I fought strongly against that, and I succeeded in having it substantially narrowed.

I try to publicly announce subpoenas as soon as I can.


Impressive job of saying just what I was about to say!

Just a note that some may find interesting:

The forum now displays SegWit-in-P2SH addresses when asking for payments for evil-IP fees and copper-member promotions, and I will also be sending them to advertisers. Moderators can also use either type of SegWit address for their mod payments.

Upgrading to SegWit was especially important for the forum because we receive tons of small evil-IP fees, and this later results in massive consolidation transactions. P2SH-wrapped-SegWit will reduce the size of these by around 20%, which will be good for both the forum and the Bitcoin network. While using native SegWit addresses (starting with bc1) would be even more efficient, I don't consider it generally appropriate to use those yet because paying to them is not widely supported. And showing both types of address would create more confusion than it's worth, I think.

In the forum's case, upgrading required just upgrading bitcoind to 0.16 and changing two lines of code elsewhere. In some other cases it could be a little more complicated, depending on how exactly you are accepting/sending Bitcoin payments. There's no rush to upgrade to SegWit, especially for things like cold wallets; paying to non-SegWit addresses may well be supported for over a decade into the future, and there's no problem whatsoever with storing BTC in non-SegWit addresses. But in many cases upgrading will provide you with significant benefits, so it's something to think about.

bitcointalk.org will never hold people's money like that, even temporarily. Perhaps someone else could set up such a hub, though it's really sub-optimal. For now, on-chain fees are low enough that on-chain transactions are probably better, though fees will eventually rise again; hopefully by then some new tech will have either improved LN in this area or provided a good alternative to LN for these use-cases.

In all payment-channel systems, including LN, the recipient has to be online to receive a payment. AFAIK the only way to receive a payment while offline would be to have someone else accept the payment on your behalf, absolutely trusting them with the BTC, at least until they can forward it to you. For this reason, LN isn't great for forum transactions, where you usually can't expect the recipient to be online.

Here you go: https://bitcointalk.org/merit.txt.xz

Similar to trust.txt.xz, it'll be updated weekly. It will show only the last 120 days of data; someone else should archive the old ones if you want them.

I am especially interested in analyses of this data which could point to sub-communities where the initial sMerit is exhausted and new sources are necessary, and people who might be good merit sources.

Edit: Note that for a little while I had user_to and user_from as names, but I decided to change it to IDs.

30 days ago was Jan 30. Since Jan 30 you've sent 391 sMerit. Your merit source is 300. So you're out of source merit and are spending your own sMerit.

Also, I just realized that spending your own sMerit also counts against your source for the following 30 days. That's a bug, but I'm probably going to have to completely rewrite the sMerit-calculation algorithm to fix it...

The state of anonymous file-sharing (and anonymous Web hosting) is very poor. The most commonly-used solution is Tor hidden services, but those have terrible security. They are weak to intersection, timing, and DoS attacks. Plus, Tor is fundamentally centralized, relying on a fixed set of Tor directory authorities to manage the network. I have no doubt whatsoever that the NSA & friends could easily find the true IP address of any Tor hidden service. I think that they only hold off on doing so in most cases because they like to build a false sense of security while holding that tool in reserve.

The ultimate solution to this is IMO to switch from a network architecture of "point-to-point" to a network architecture of "distributed data-store". Instead of having clients talk to a server somewhere (even behind 7 proxies), you should have the "server" upload their data to some "anonymous cloud", and then have clients download the data from that cloud, without ever needing to have any sort of connection to the server machine. This nicely addresses the most serious attacks against Tor: intersection & timing attacks against the server are much more difficult, since the server does not need to be online or sending data at the same time as the client, and DoS attacks are handled by the system itself.

Freenet and GNUnet are distributed data-store systems. Freenet even has a number of websites and social networks which function on the data-store model. It is possible to redo nearly every website under this model, though it is a major change.

But one major problem with Freenet and GNUnet is that their security (especially in Freenet's case) is ad hoc: they basically jam the system with a bunch of obfuscation and hope that it works. I have no confidence whatsoever in their security as a result. They're both probably especially vulnerable to sybil attacks when used in their opennet modes. They're also very slow, and they would probably fail to provide censorship-resistance if seriously challenged.

---

What I propose instead is something like the following system. (Note however that this is only a half-baked idea...)

Data stores

There are a handful of data-store-servers, each internally centralized. The job of one of these data stores is to maintain a key-value data-store, provide it for people to download either in full, via something like rsync, or via a private information retrieval (PIR) scheme. When PIR is used, it allows clients to download one or more keys from the server without giving the server any information about what keys were downloaded, providing the client with perfect anonymity even when the entire connection is observed by an attacker.

Data store descriptors

Clients will download "data-store descriptors" describing a number of data-stores. Eg:

It is not important that clients have some particular combination of data-stores. They can download as many of these descriptors as they want, whenever they come across them. The core software for this system might come with some built-in, but more could be added by the user.

Data-stores can charge for uploads and downloads. This can be done perfectly anonymously using blinded bearer certificates, or less-perfectly via eg. Bitcoin-Lighting.

Uploading data

You want to upload song.mp3.

1.Encrypt it with a random key.
2. Break it into fixed-size chunks, say 16kB in size.
3. Choose at least 3, but maybe more, data-stores that you know about.
4. Download all or a large random selection of recently-uploaded data on each of the chosen data-stores.
5. For each of your chosen data-stores, randomly classify each as either Original or Derived, but at least one must be Original.
6. Assume that you're using exactly 3 data-stores. Let your data be D, and the data at each of the data-stores be X, Y, and Z. Between 0 and 2 of X, Y, and Z will already be known. Randomly select the not-yet-known values so that D = X+Y+Z. For example, if you chose Y as Derived and X&Z as Original, you would randomly choose X&Z such that X+Z = D-Y. Prepare to upload the new data block(s) to the data-store(s). (You can use any reversible operation to combine the data; maybe addition isn't ideal.)
7. Repeat steps 5-6 for each block of data.
8. Create and prepare to upload your metadata block, which will have a table like:
If your table is more than the block size, you can put a pointer to a continuation block at the end of it. (Or structure it as a tree.)

Finally, you should upload all of the blocks that you have prepared to upload, but you should do it in a random order and spread out over time. The more time you put between each block, the more difficult it will be to connect the blocks together.

Then you'll get a CHK URI that you can give to people which looks something like:
CHK@store1+store2+store,key1,key2,key3,decryption_key
eg. CHK@alpha+beta+gamma,SVbD9~HM,nzf3AX45,yFCBc-A4,bA7qLNJR7IXRKn6uS5PAySjIM6azPFvK~18kSi6bbNQ

PIR schemes don't give anonymous uploading natively, so there will need to be some onion routing thing between you and the server. But higher latency is OK here, and there are alternatives to Tor's naïve onion routing such as Riffle, so I think that this can be made very anonymous.

Downloading data

You were given a URI like the one above which leads to song.mp3.

1. You need to have previously downloaded descriptors for all of the data-stores in the URI.
2. From each data-store, download the listed keys using the anonymous PIR scheme, and add the data together. This will get you the first block which lists all of the others
3. Download all of the other blocks in the same way.
4. Once you have all of the blocks, concatenate them together and decrypt them with the decryption key in the URI.

Plausible deniability and censorship-resistance for data-stores

The key advantage of this scheme compared to things like Freenet is the plausible deniability and censorship-resistance for the ones storing the data. On Freenet, if you're running a node and someone gives you a CHK that they say is a copyright violation or whatever, it is technically possible for you to expunge that CHK from your node, and so maybe you could be forced to do so. Same for Tor hidden-service DHT participants.

But for a data-store in this scheme, if someone gives you a CHK that they demand be removed, they can say that some data in your data-store is being used by that CHK, but they can't say whether that data belongs to that CHK. The data may have been uploaded by someone else entirely, and if you delete it, you may break the original CHK which is totally legitimate, as well as any others which subsequently used that data. It's like creating new content by pasting together words cut out from a newspaper. I suspect that this aspect will make the system totally immune to DMCA takedowns and similar.

Because of this plausible deniability and censorship-resistance, an increased level of centralization can be accepted. You can more reasonably have a few dozen extremely fast, powerful data-stores rather than thousands of nodes on home Internet connections. This eliminates sybil attacks (on nodes) and improves the speed of the system. And while there are few data-stores, they are not an integral part of the system as a whole (ie. they don't "vote" or anything), and they can be fairly easily replaced if necessary.

Extra thoughts

It's maybe not necessary for each block's components to be stored on separate data-stores.

A CHK will stop working if any of its data-stores goes down. I wonder if, instead of addition, you could use an error-recovery scheme such that you only need 3 of 4 components of each block, or something like that.

Data-store blocks might have an expiration, but it should be either uniform across the data-store or very coarse-grained.

Data-store keys should be short, do not need to be unpredictable, and do not need to be user-definable. Data-stores might assign sequential keys starting at 0, and fill in gaps as blocks expire.

That Dave's Wallet Recovery exchange was embarrassing, but alia still insists that a Skype interview will exonerate her. I have a sort of script written for the interviewer: PM me if you're a somewhat-notable member and are willing to do it.

I find the little-brother story almost entirely unbelievable, but someone trustworthy could try skyping Alia, get both her and her brother on video at the same time, and interview them about this matter to check that they're not just actors.


No match. Singapore is famous for its economic freedom, so it may actually be a legit method.

Re: [CHEAPEST ON BCT] [NEW] Alia's Lending Service [LOW INTEREST] [0.1% DAILY]

"sometimes use each others' accounts"

Yes, a change from alia_armelle to alia is a minor change which I would normally do for anyone who can convince me to spend time on it. (If I recognize your username, I'm much more likely to handle your requests. I'm also much more likely to look into your scam accusations...)

I never accept payment for this sort of thing.

Upon investigation, alia == favours via IP evidence and a now-deleted mistaken bump of one of alia's threads. Info in favours' posts disproves alia's claimed identity.

---

My neutral rating was intended only as a statement of fact. alia was verified on /r/GirlsGoneBitcoin. Here are the GirlsGoneBitcoin verification procedures: https://www.reddit.com/r/GirlsGoneBitcoin/wiki/verification . It's intended to verify that the user is not just giving out random images found online and calling them their own, not to actually verify their identity. The person in the verification photos is definitely female, and is extremely unlikely to be 15. Furthermore, alia has had a number of customers for her camgirl stuff on this forum who were apparently mostly satisfied. Therefore, it is most likely that the person behind the alia account was hiring a camgirl to do their camgirl-related work.

Alia was immediately on my radar when they appeared out of nowhere with a clever way to get a trust rating (even neutral) from me. And then they went on to invade every forum trading industry. I was hoping that it was just an impressively ambitious person, but as I kind of feared, I guess it was a setup for a long con or something.

The best practice currently is to give people P2SH SegWit addresses when people are paying you, but to support/allow sending to bech32 addresses when you're paying people. bech32 addresses are strictly superior except for issues of backward-compatibility, so eventually everyone will switch over, but it'll probably take a few years; it shouldn't be a format war situation unless someone decides that they hate bech32 and come up with a totally new alternative.

The minor software bugs will eventually get worked out. It's still new software. C isn't the greatest choice of language, but it can be made to work with enough persistence.

I agree that it is in some ways unfortunate that most people are focusing entirely on LN rather than other methods of fast & cheap off-chain payments like hub-and-spoke, federated sidechains, or blinded bearer certificates. While LN is the most decentralized off-chain solution that's been proposed AFAIK, it's also by far the most complicated. Even though you can sort of use it now, I'm not so sure that we're going to be seeing ordinary people using it regularly in the next year. And even if we do, it'll only be to pay established merchants, since no solution has yet been devised for LN payments where the recipient is offline; in practice, this will prevent peer-to-peer LN payments (eg. forum trades) from being practical.

LN will probably be the long-term solution to Bitcoin payments, but in the short-term I've long advocated for federated sidechains, which could be an ultra-simple drop-in replacement for on-chain Bitcoin transactions, or blinded bearer certificates, which immediately provide perfect anonymity as a side benefit. Both of them are much simpler than LN on a theoretical level, though both have the cost vs LN of increased centralization. I was really hoping that RSK would provide a federated sidechain usable for fast & cheap payments in this way, but so far I've been disappointed there. And nobody is working on blinded bearer certificates AFAIK.

(But I'm not working on any of this stuff, so I can't complain too much...)

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.

Stats

Exact historical impression counts per slot:
https://bitcointalk.org/adrotate.php?adstats

Info about the current ad slots:
https://bitcointalk.org/adrotate.php?adinfo

Ad blocking

Hero/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 ads

Make sure that your ads look good when you download and edit this test page:
https://bitcointalk.org/ad_test.html
Also 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 rules

You 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.

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.