You are only allowed to sell accounts/invites that you legally obtained yourself or through legitimate trades. If you did anything illegal in order to obtain an item, then you can't trade it on bitcointalk.org. Anyone found breaking this rule will be banned.

Product/gift codes seem pretty separate, ontologically-speaking. Maybe they should get yet another section, if there is a significantly high volume of such trades?

We're considering creating a subsection called "Invites & Accounts" under Marketplace -> Goods -> Digital Goods. This would segregate a lot of Digital Goods topics, providing for improved organization and more effective moderation.

Thoughts? Should other or different things be included in this new section?

The 200^th forum ad round will be in about a week. Normally I do some something on significant numbers like this. Any suggestions?

P.S. I need to think of some special rules for the 200^th round's auction, so there won't be a new auction for a couple days.

You have negative trust from my perspective, so I won't accept your bid.

Auction ended. Final result:
Slots BTC/Slot Person
1 0.40 XBTFreelancer
1 0.35 Gunthar
2 0.35 lightlord
1 0.30 Coinzilla.io
1 0.30 BitDouble.io
1 0.30 lightlord
2 0.25 Lunarbets

This idea just occurred to me. I haven't tried it, so maybe something makes it impossible.

1. Buyer wants to buy BTC from Seller.
2. Seller secures the BTC in a 2-of-3 multisig escrow along with Buyer and a mutually-trusted escrow. (A 2-of-2 no-third-party escrow could perhaps be used instead if the Buyer already has some BTC to use as collateral.)
3. Buyer buys an Amazon gift card at a physical store using cash.
4. Seller indicates to Buyer a nearby Amazon Locker location, and signs this message with a key known by the escrow to belong to Seller.
5. Buyer creates a new Amazon account with a fake name near the indicated Amazon Locker location, and adds this Amazon Locker to his account.
6. Buyer uses his gift card to send something money-like to the Seller's Amazon Locker. For example, physical gift cards or gold could be used.
7. Buyer forwards the Locker code to Seller. Seller picks up the item and releases the BTC to Buyer.
8. If Buyer fails to send the item, the escrow can release the BTC back to the Seller after a time-out period. If Seller fails to release the BTC after receiving the item, Buyer can prove with near-certainty that he held up his end by giving the escrow the Seller's signed message indicating the correct Locker location, along with Amazon's DKIM-signed Locker-code email. Theoretically, Seller could intercept the delivery before Buyer gets there, but this seems pretty difficult since the Locker is likely to be far from Seller. If necessary, some TLSnotary stuff could probably be added to reduce this risk.

At the end, no info about the participants is revealed except for the very-approximate location of the Seller. (And perhaps Amazon has some way of tracking the very-approximate location of the Buyer based on where the gift card was purchased.)

Buying the gift card and shipping should have no cost. The overhead will be in converting the item back into cash. With gold coins it looks like it'd be about 18% overhead, which is pretty bad, though still often better than the localbitcoins spread. Maybe you could find something that is more efficiently convertible to cash than gold coins, or the Seller could ask to receive things that he actually wants from Amazon.

This is better than just giving someone an Amazon gift card code because:

- It's innately irreversible.
- Due to Amazon's DKIM signature, the transaction is more easily provable -- the escrow has to do very little thinking in case of a dispute.
- Unless a gift-card-code recipient takes unusual steps, this way is more private.

I will award BubblesBit 0.2 BTC for the first nearly-complete solution and Bitsky 0.05 BTC for another nearly-complete solution which is shorter and more specific. In both cases, the additions significantly change test case #3, but I can work around this.

For those wondering, test cases 3 and 4 were not broken, but I included them to make sure that they didn't become broken due to additions.

Thanks to everyone who put time and thought into this.

(Bounty claimed.)

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.