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. 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.05.
- The bidding starts at 0.25.
- 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.
- 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.

Sorry, your service looks too risky. Maybe try again in 3-6 months.


Your site looks too immature/risky. It needs to be established more.


No, cancelled/rejected bids do not affect other bids. They are just cleared from the auction list. If you need to know before the end of the auction whether someone's bid is going to be rejected, PM me. If my answer comes too late for you to adjust your bid downward, and you can reasonably make the case that the person's bad bids unfairly inflated the price, then I might be willing to negotiate a lower price after the auction. But you can't just assume an entirely different auction status or we'll have a big mess.

Since you and BitDouble.io clearly had this misunderstanding, I will interpret your posts expressing this misunderstanding as creating new bids.

For clarification, all of the accepted bids were:

Slots BTC/Slot Person
1 0.65 Lunarbets (13)
1 0.65 XBTFreelancer (14)
1 0.65 BitDouble.io (15)
1 0.50 Duetschpire (7)
1 0.50 BitDouble.io (10)
1 0.50 Gunthar (11)
1 0.50 lightlord (12)
1 0.50 bizzyb (16)
2 0.50 XBTFreelancer (17)
1 0.50 BitDouble.io (19)
3 0.45 Lunarbets (5)
1 0.45 Gunthar (6)
4 0.45 XBTFreelancer (8)
1 0.45 BitDouble.io (9)
3 0.45 Lunarbets (18)
2 0.40 XBTFreelancer (4)
1 0.30 Gunthar (1)
3 0.30 Lunarbets (2)
1 0.30 bizzyb (3)

Removing all but each person's last bid according to the biding order in parentheses above:
Slots BTC/Slot Person
1 0.50 Duetschpire (7)
1 0.50 Gunthar (11)
1 0.50 lightlord (12)
1 0.50 bizzyb (16)
2 0.50 XBTFreelancer (17)
1 0.50 BitDouble.io (19)
3 0.45 Lunarbets (18)

Since 9 slots are available, the final result is:
Slots BTC/Slot Person
1 0.50 Duetschpire
1 0.50 Gunthar
1 0.50 lightlord
1 0.50 bizzyb
2 0.50 XBTFreelancer
1 0.50 BitDouble.io
2 0.45 Lunarbets

medicine has been inactive for a long time, so a new moderator is needed. Please post here if you want to be a mod, and also if you support anyone in particular for mod.

Zeroxal was cleared of past rule-breaking.

That appeared briefly while I was in the middle of improving something. No need to worry.

Is this using Bitcoin Core's block creation code?

I looked at percy++, but it wasn't immediately clear to me what version of single-server, computation PIR it was using. XPIR had a nice paper that I could read. percy++ could be better, I don't know. Though it seems to be focusing mainly on the version of PIR where multiple servers are involved and assumed to be non-cooperating, which I feel is an assumption that's too difficult to ensure in practice for this situation.


Perfect! I was thinking that an RPC method like that was exactly what was needed. Non-PIR services to provide that data will also be useful in the near future -- loss of rescan was a huge downside to pruning.


Cool!


It does seem to have constant size, but it doesn't seem that the size affects efficiency much. The entries also seem to be streamed to clients in order, since the XPIR paper talks about streaming video. So if a record is 10MB composed of 250kB followed by 9.75MB of zeroes, the client could stop reading at some random point after receiving their 250kB.

If that doesn't work, another thing that occurred to me is that you could have lists of txids, and then another PIR database for fetching transactions. Or even just the simple piece of data that all of the address's transactions appear between blocks x and y, which the client could then go download elsewhere. Perhaps the database could degrade through all three of these possibilities depending on how much transaction data there is.

I'm glad this stuff is on your mind!

Currently, all lightweight nodes have to more-or-less give a list of all of their addresses to someone else in order to find their incoming and outgoing transactions. This totally destroys their privacy because it connects all of their addresses together, even if they're behind Tor. Some wallets try to obfuscate this with bloom filters, but research has shown that this isn't all that effective at maintaining privacy. Bitcoin Core avoids this problem by downloading the entire block chain, but this uses a lot of bandwidth, and if you don't store the entire block chain, you have to download everything again if you want to rescan.

I found that there is a (beta) library called XPIR which may be able to improve this. It uses homomorphic encryption to allow for a server to have a database which clients can query, but without the server or any listeners knowing which entries in the database the client is querying/receiving. So clients could ask the server (encrypted), "please give me all transactions associated with address ____", and the server would be able to provide this data without knowing anything about the client's query. This would significantly improve privacy.

Running a server will be pretty resource-intensive, so this isn't something that every full node is going to be doing. However, it would be appropriate for Electrum servers, sites like GreenAddress, etc.

I haven't actually tried the software, but looking at the paper, here's how I think it'd work on a technical level:

 - The database to be queried must be structured as index -> value, where indices must be sequential integers starting at 0, and clients can only query for specific indices. So the first step is for the server to publish a mapping between all possible scriptPubKey queries and their indicies. This can be done by hashing each scriptPubKey seen in the block chain (maybe with wildcards to handle cases like stealth addresses), sorting the hashes, and giving each one a sequential index. All clients need to download this initial mapping. If the hash is 128 bits and the index is 64 bits (both of these could maybe be shortened), currently the mapping would be around 10.3 MB with today's 429k unique addresses. Everyone gets the same mapping, so there's no need to download it in any special anonymous way.
 - The efficiency of the database goes down with the number of entries. Here, "entries" is the number of possible scriptPubKey queries. So each server should actually have several XPIR databases, each of which will contain perhaps around 100,000 possible scriptPubKeys. Info about which scriptPubKey ranges belong to which database will also have to be downloaded by clients, but this is a negligible amount of data. Each database needs to start its indices at 0, so the client will have to adjust the global index down according to which database it's querying. Segregating the scriptPubKeys like this allows the server to know that the client has some address in that range, but there are enough addresses to make this not-very-useful. The client could also send dummy queries to disrupt even this.
 - The client would just send one query for every address in its wallet. For each one, they'd get all of the address's transactions along with its merkle branch linking it to the block chain. From page 14 of the XPIR paper, it looks like you can very roughly expect to download your transaction data at 12.5 kB/s, with a latency between first query and initial transaction data of 10-500 seconds depending mainly on the client's upload speed. These speeds seem OK.
- If clients are only interested in addresses that currently have BTC, you can significantly reduce the size of the database, and therefore increase efficiency. Similarly, the database size can be reduced for clients that have been online for a while and are therefore only interested in new/recent blocks.
 - I'm not sure how many clients a reasonable server could comfortably handle. If it's not very many, then servers might need to charge for this. Maybe they could have a free queue, and then the possibility of paying to jump the queue. They could use blinded tokens to accept micropayments anonymously. The current XPIR library seems not to be very optimized, especially for multiple simultaneous clients, so performance improvements are probably possible.

Thoughts?

I wrote a page on the wiki about this a while ago: https://en.bitcoin.it/wiki/Passphrase_generation#Generating_keys.2C_seeds.2C_and_random_numbers_.28Advanced.29

My recommended method is to just hash a string containing the dice rolls. The rolls will contain enough entropy in themselves (if you're using enough dice), and the hash should not degrade this in any significant way.

dPoW relies on centralized notaries which collect data-to-be-timestamped and then insert just a few hashes of this data into each Bitcoin block. The notaries are chosen via PoS, but I still consider this to be significant centralization. Factom works similarly, though AFAIK without the PoS element. dPoW and Factom could perhaps be useful if used well (though I have serious doubts about whether this is actually happening), but I'd prefer to minimize centralization as much as possible.

Yes.

They're not anonymous.

There are many cryptographic techniques for doing anonymous voting. This is a well-studied topic.

I don't really recommend forum voting for sensitive topics, but if you really want to, you can do something like this:


As the number of respondents increases, the random noise evens out, and at infinity the actual percentages will be exactly the same as if this randomization stuff didn't exist. (Assuming that everyone actually follows the instructions.) You can use statistical techniques to exactly quantify this stuff. But yet each person has plausible deniability. Note that this scheme assumes that everything associated with random.org is perfectly secure, which may not actually be a safe assumption -- it'd be better to use dice or a local CSPRNG, but that's more difficult to get people to do.

An idea for safely using Bitcoin for generic timestamping just occurred to me. I'll roughly describe it here. (Though there's a good chance that someone has thought of this already, and I'm just poorly reinventing it.)

Do a softfork with these two new rules:

1. Miners will construct a separate hash tree called the chain tree, which I'll explain more later. Some special area in blocks is reserved for the root hash of this tree. For example, this could go in the coinbase transaction or in the first transaction after it.
2. When a transaction has an output with the special form <arbitrary magic constant> <merkleHash> OP_RETURN, then a block containing the transaction is only valid if merkleHash is the hash of one of the nodes of the chain tree. Therefore, a block can only be considered valid if it is transmitted with enough of the chain tree to verify all of these transactions in it, though the entire chain tree need not be known to anyone.

Each node of the chain tree would be something like:


Bitcoin full nodes do not verify anything about the chain tree unless required by rule #2 above. If there are no rule#2 transactions in a block, then the chain tree root can just be random data.

Bitcoin then becomes a generic decentralized timestamping server for an unlimited amount of data. There are several use-cases for this, including scaling:

---

You can create a chain like Bitcoin's, but with 32 MB blocks or whatever. Full nodes on this chain would need to be full nodes on both Bitcoin proper and a separate bigblock network. When receiving a new Bitcoin block, they'd download as much of the chain tree as they can, and then for nodes matching a certain chainId specified by the bigblock network specification, they'd try to download that block over the bigblock network. Maybe only the first such block would be considered valid (by some ordering specified by the bigblock network), or maybe all valid blocks in the chain tree would be accepted. The network can do whatever it wants.

No mining/PoS/etc. is necessary on the bigblock chain. Anyone can create blocks and submit them to Bitcoin miners for inclusion into the chain tree. However, an attack is possible where someone creates a valid block and gets it into the chain tree, but then refuses to actually send anyone the block until much later, rewriting history; to prevent this, each block should still have a header with a prev-block hash, and the longest chain of blocks should win.

If you're creating a bigblock block, you'd get miners to include your block's node into the chain tree by sending along with your request a transaction using the special rule#2 form specified above. There would typically be only one 0-value output in the special form, and the inputs can use SIGHASH_ANYONECANPAY so that people can work together to pay the fee. Additionally, the chain tree can actually extend inside of the bigblock chain so that bigblock transactions are part of the chain tree; then individual transaction-senders can add a similar incentive that is specific to their own transactions.

Unlike typical sidechains, this would not have SPV-level security. Even if all Bitcoin miners worked together, they could not create an invalid block on the bigblocks network that bigblock full nodes would have to accept. To achieve the same effect with sidechains, you have to do a soft-fork which adds a requirement that all Bitcoin full nodes also be full nodes on the sidechain. This might sometimes be OK, but not if the sidechain is doing something burdensome like creating massive blocks.

I don't think that you can do 2-way-peg without either more-or-less recreating normal sidechains or getting Bitcoin full nodes involved to a much greater extent (more like Peter Todd's Tree Chains idea). So the bigblocks chain described here would have to have its own currency. Whether or not this major drawback allows it to still be worthwhile, I'm not sure.

---

It works even better for timestamping applications that are less related to transactions, especially:
- As part of a decentralized DNS system.
- For general time-stamping of documents

For these, you maybe don't even need separate blocks at all: the transactions can be connected directly to the chain tree. And certainly you wouldn't need a separate currency.

I just realized that I accidentally left the "auction ending soon" ad up after closing the last auction. This auction is not ending soon, but in something like 6-10 days. Sorry about that! If anyone bid expecting to have ads up soon, you can cancel your bid.


There's no waiting period, but ads are done in fixed time periods; each auction thread auctions off slots in an entire future time period. So you can't generally advertise for just a few days.

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. 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.05.
- The bidding starts at 0.25.
- 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.
- 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.

Auction ended, final result:
Slots BTC/Slot Person
3 0.45 lightlord
5 0.40 coinmallio
1 0.40 Chronobank

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. 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.05.
- The bidding starts at 0.25.
- 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.
- 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.

You are a newbie, so you have to PM me first. Please carefully read the auction rules next time.


Bids must be evenly divisible by 0.05, so I rounded this down to 0.60, but that's not enough to win slots in this case.

Auction ended. Final result:
Slots BTC/Slot Person
2 0.60 Randian Hero
3 0.60 lightlord
1 0.60 BitDouble.io
3 0.60 Lunarbets

I think that I found the problem. My anti-DDoS system got confused by the new year and was randomly banning IPs. These bans are removed and the bug is now fixed. Sorry about that!

This may be resolved now, but if you had this problem, please PM me:

- The IP address that you think got banned.
- The Web browser and operating system you use the access the forum.
- Any other software you use to interact with the forum, such as RSS readers.