Bitcoin Forum
December 12, 2017, 09:59:58 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 [16] 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 ... 346 »
301  Other / Off-topic / Thoughts on Cloudflare and denial of service attacks on: February 25, 2017, 04:12:04 AM
In discussions about the Cloudflare disaster, I've seen people saying that protecting against denial of service attacks without Cloudflare is basically impossible. While it is much more difficult, it's not impossible.

First of all, there's the major issue of sites giving their HTTPS keys to Cloudflare. One of the main reasons that Cloudflare needs to see into HTTPS is so they can detect application-level attacks, such as slow or large HTTP requests, SQL injections, etc. These sorts of attacks can all be fixed server-side, and furthermore Cloudflare cannot fix these attacks in general. Relying on Cloudflare to protect against all such attacks is really "security through obscurity", and will not stand up against a serious attacker. If you handle application-level attacks on your own, then security-wise, there's very little reason for Cloudflare to be able to see into HTTPS. They should be able to work purely at the TCP/IP level.

(Looking into HTTPS is also needed for caching at the DDoS-protection server, but for dynamic web applications, caching can't be used all that much anyway. Cloudflare also uses their ability to man-in-the-middle HTTPS connections in order to display a CAPTCHA, but I think that this is unbelievably annoying and unnecessary.)

Aside: Cloudflare offers a piece of software which they claim allows you to use their service without giving them your HTTPS key. While it allows you not to give them your key, the software sends each HTTPS session key to Cloudflare, allowing them to do pretty much everything they could do if they had the key. Maybe it's a little better than nothing, but it's mostly a false sense of security.

Where DDoS providers are really useful is against attacks at the network and transport layers. Assuming application-level attacks are already addressed, the two most powerful DDoS strategies are:

- TCP SYN and UDP floods, which work by overwhelming the server's ability to track and process connections at a software level.
- Traffic floods, which work by overwhelming the networking hardware either leading into the machine or upstream of the machine.

Most sites today will be taken down by even a small SYN or UDP flood. However, for attacks up to a moderate size, these attacks can be mitigated quite efficiently by blocking UDP somewhere upstream of the server (unsolicited UDP connections are unused by most servers) and having a SYNPROXY iptables setup on the server. If all sites did this and handled their application-level DoS attack vectors, then the common Cloudflare subscription types would be completely redundant, since Cloudflare will not protect against large attacks without a very expensive subscription anyway.

For large attacks, you need to handle it by:

- SYN/UDP floods: Have multiple SYNPROXY servers in front of the application server, or have several reverse proxy servers in front of the application server, or have multiple application servers which can be used in parallel. The main point of this is to filter out bad packets before they can clog up the application server, not really to cache or whatever.
- Traffic floods: Ensure that the complete path between the Internet and your outermost server(s) can handle the bandwidth of the attack. Oftentimes, some Ethernet switch just outside of your server will be the bottleneck. Again, having multiple outermost servers is beneficial because it splits up the attacker's traffic.

These large attacks are where you really want a DDoS-protection company; while it is completely possible to set up the above-mentioned protection against large attacks by yourself, it is expensive and difficult. And because the actually-dangerous attacks are at the network or transport layer, there's really no reason for the DDoS protection company to need to see into the underlying HTTPS traffic (though most of them want to do this anyway...). However, although there are many DDoS protection companies that can protect you from large DDoS attacks, they are very expensive; if you can get it for less than a few hundred dollars per month, then the DDoS protection company is probably lying about what you're actually getting.

The sub-$200/month Cloudflare subscription that most people use is a cheap magic bullet for driving off only the weakest attackers, while also selling your soul to Cloudflare.

If I was going to design something like Cloudflare, I'd have it do just two things:

1. Across all sites hosted on the service, I'd monitor the behavior of client IPs to classify IPs as "probably a real person", "probably an attacker", or "new/unknown". Based on these classifications, I'd apply rate-limits and blocks per IP address in order to help sites screen out abusive traffic. This sort of wide view of IP address behavior is something that a service-provider for many sites can do better than a single site.
2. While having a bunch of Internet-facing servers and super-high-capacity connections, I'd block UDP and handle the TCP handshake on behalf of the real server, only forwarding through TCP connections which complete the handshake. This increases latency somewhat, but probably not that badly, and it could activate only when a DoS attack seems to be actually happening. It could also take into consideration the IP address classifications of the previous point (but with the knowledge in mind that IP addresses might be fake before the TCP handshake completes).

This'd protect against DDoS attacks without significantly hurting security.



It's bad that DDoS attacks are something that needs to be worried about. It is especially bad for anonymity, since currently websites must be able to block IP addresses in order to protect against application-level DDoS attacks; IP addresses are the only scarce resource that attackers can be forced to burn through. If a site allows connections via Tor, then during a DDoS via the Tor network, all of Tor is going to need to be blocked in order to block the attacker. If a site allows connections via a Tor hidden service, then during a DDoS via the hidden service, the site is going to have to shut down the hidden service. By design, there's no way of distinguishing good Tor users from bad Tor users, so if serious abuse is coming via Tor, you just have to block Tor entirely.

This is a serious flaw in the Internet which needs to be fixed. One solution would be to add some sort of cost to packets and/or connections, such as a proof-of-work or micropayment. Ideally, proof-of-work would be added to IP packets and dropped by backbone routers if insufficient, though I'm not sure how you'd coordinate the correct PoW difficulty. Maybe you could have a minimal PoW difficulty checked by backbone routers and then a much larger PoW difficulty at the destination.

Concerning Tor and similar darknets, I also think that it would be useful to have an HTTP extension for expensive, long-term proofs-of-work. For example, maybe you'd have to work on the PoW for several hours before you could post on a Tor-based forum, but then you could reuse that PoW at any later time on that site. This way, there'd be some cost associated with people having their account/PoW banned for abusive behavior: they'd have to recompute the PoW. This would replace the currently-common mechanism of banning IP addresses, which is impossible on Tor hidden services.

I've also been thinking recently that the whole structure of the Internet may be largely incorrect. If the Internet was a distributed data store like Freenet instead of a point-to-point system, DoS attacks would be impossible unless you managed to attack the entire network as a whole. It'd also be much easier to achieve anonymity, since all low-latency point-to-point anonymity systems such as Tor are terribly weak to intersection and timing attacks, but these attacks don't really work in the distributed-data-store model.

I think that ~99% of things done on the Internet can, with work, be converted to the distributed data store model. Streaming content, static websites, and email are pretty easy. Dynamic Web applications like forums and Facebook-type sites can be done using static pages with fancy JavaScript applications which work within the distributed-data-store framework. (This would be quite a change in how people write web applications, though; there'd certainly be no way to quickly/easily translate some PHP code directly into the data-store model, for example.) The only thing that this model is not very good at is one-time one-to-few communication such as video/voice calling; for these few use-cases, the point-to-point model could still be used.
302  Other / Meta / Re: Bitcointalk affected by Cloudbleed? on: February 24, 2017, 03:56:35 AM
No, only sites which used Cloudflare could've been affected.
303  Other / Meta / Re: Ad round 200 raffle on: February 21, 2017, 10:54:14 PM
He won't get VIP status. The bonus prize was two of the perks of VIP status: changing your username at will and being able to set a custom title.
304  Other / Meta / Re: Ad round 200 raffle on: February 20, 2017, 10:01:36 PM
(I was going to wait 6 blocks, but I got impatient.)

Code:
RESULTS
Block number: 453955
Block hash: 0000000000000000006c58a0ae184c4f68c894c5c25d67b97a795c87699993f7
Raffle ID: bitcointalk.org round 200

WINNING TICKET: 771
WINNER:  YoBit

Congrats to YoBit!

This seems like something new.  Very cool.

New, but only a one-time thing for the 200th ad round.

Is block hash actually random? I heard some discussion about this before but I don't remember if there was any decent analysis done.

It's not random in the sense that it is uniformly distributed. This is obvious if you look at it because it always starts with a bunch of zeroes. However, it is basically impossible to predict the hash long in advance, so it makes a good seed for generating random numbers that are unknowable before the block, but can be publicly calculated after the block.

Miners could throw away blocks that they generate or even try mining backward in order to affect the raffle result. However, this is very expensive mining behavior, so the raffle would have to have a value of at least hundreds of BTC to make this rational behavior for them; in such cases, you can adjust the procedure in order to prevent this attack.
305  Other / Meta / Ad round 200 raffle on: February 19, 2017, 10:53:38 PM
About a day from now, the raffle draw for the ad round 200 bonus prize will be conducted. Here are the raffle ticket numbers (ranges are inclusive on both sides):
1 - 100: BlockchainOS
101 - 184: Gunthar
185 - 226: BitDouble.io
227 - 841: YoBit

The winner will be determined by generating a random number between 1 and 841 using my raffle script with inputs:
- Block #453955
- The hash of block #453955 (to be determined about a day from now)
- Raffle ID: bitcointalk.org round 200
- Ticket assignment as above, from the bid-winner table's ordering

If you run my raffle script, you can give it the following input once block #453955 is solved to see who won.
Code:
453955
INSERT BLOCK HASH HERE
bitcointalk.org round 200
BlockchainOS
1
Gunthar
0.84
BitDouble.io
0.42
YoBit
6.15

c

Good luck!
306  Economy / Auctions / Advertise on this forum - Round 201 on: February 17, 2017, 03:30:22 AM
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.
307  Economy / Auctions / Re: Advertise on this forum - Round 200 *SPECIAL BONUS PRIZE* on: February 17, 2017, 03:22:16 AM
Auction ended, final result:
Slots BTC/Slot Person
 2 0.50 BlockchainOS
 2 0.42 Gunthar
 1 0.42 BitDouble.io
15 0.41 YoBit

In a few days, I will make a separate post in Meta with more details on the raffle drawing, which will occur a couple of days after that.

Thanks to all participants in this lively auction, and to all participants in the last 199 auctions!
308  Economy / Auctions / Re: Advertise on this forum - Round 200 *SPECIAL BONUS PRIZE* on: February 16, 2017, 08:02:04 PM
The auction continues, but FYI, here is the current status:
Slots BTC/Slot Person
 2 0.50 BlockchainOS
 2 0.42 Gunthar
16 0.41 YoBit

I wrote code to conduct the raffle: https://github.com/theymos/raffle . (I wrote it generally, so it may also be useful for others.) The raffle ID will be "bitcointalk.org round 200". I'll announce the block number and ticket numbers some time after the auction is over.
309  Economy / Auctions / Re: Advertise on this forum - Round 200 *SPECIAL BONUS PRIZE* on: February 15, 2017, 07:20:25 PM
2 @ 0.5

You're a newbie, your bid is insanely high, and I don't know what you're going to advertise, so I won't accept your bid.

5 - @ 0.15

Sorry, your site apparently just launched, and is based on taking deposits, so I think that it's too high-risk for now. Try again in a few months.

The auction continues, but FYI, here is the current status:
Slots BTC/Slot Person
01 0.22 modernbuddha
03 0.21 Gunthar
05 0.21 RawCrypto
11 0.20 YoBit
310  Other / Meta / Re: Suggestions for 200th ad round? on: February 13, 2017, 06:47:20 PM
Thanks for the suggestions, everyone. Combining some of the suggestions here, I decided to introduce a bonus prize consisting of some of the VIP perks, and I also changed the auction rules to encourage more active bidding. Here's the auction: https://bitcointalk.org/index.php?topic=1789075.0
311  Economy / Auctions / Re: Advertise on this forum - Round 200 *SPECIAL BONUS PRIZE* on: February 13, 2017, 06:43:34 PM
Note the following differences from a normal auction:

- The bidding starts at 0.05 BTC instead of 0.25 BTC
- All bid prices must be evenly divisible by 0.01 BTC instead of 0.05 BTC
- There are 20 slots instead of 10. Each slot will have a 1 in 20 chance of appearing in places where ads appear. And all 20 slots are up for auction here.
- The auction will end 2-5 days from the time of this post, which is shorter than normal.
- If you win slots, you have a chance of winning the bonus prize.
312  Economy / Auctions / Advertise on this forum - Round 200 *SPECIAL BONUS PRIZE* on: February 13, 2017, 06:43:08 PM
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.

For round 200, there will be 20 total ad slots which are randomly rotated. So one ad slot has a one in twenty chance of appearing. All 20 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 twenty slots are filled.

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.01.
- The bidding starts at 0.05.
- I will end the auction at an arbitrary time. For round 200, I will try to end the auction sometime between 2 and 5 days from the time of this post.
- 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.

Round 200 bonus prize

To celebrate 200 rounds of forum ads, in this round, if you win an ad slot, you have a chance of winning a bonus prize. The bonus prize is that you will be given the following abilities:

- You will be able to change your display name at will in your profile settings.
- You will be able to set a custom title of your choice at will in your profile settings.

A custom title is a short piece of text which appears above your poster rank like this:


These abilities are subject to moderation, and can be taken away for any reason at our sole discretion. Furthermore, it is not guaranteed that you will be able to do these things forever, since software changes could conceivably make either or both of these powers impractical to support.

You can transfer the bonus prize one time immediately after winning it if you wish, but not later.

One person will win the bonus prize. Your chance of winning is proportional to the percentage of round 200's total revenue which comes from you. So if for example you bid 5@0.5 for a total of 2.5 BTC, and the other 15 slots were sold for a total of 7.5 BTC, then you would have a 25% chance of winning the bonus prize.

I will select the winner randomly by relying on future block-chain data. I will post the details of exactly how to calculate the winning numbers, which winning numbers each person needs to hope for, which block will be used to generate the winning numbers, etc. after the auction is over and the slots are paid for.
313  Economy / Invites & Accounts / Hacked invites/accounts are not allowed on: February 10, 2017, 11:21:57 PM
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.
314  Other / Meta / Re: Digital Goods -> Invites & Accounts on: February 07, 2017, 02:53:11 AM
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?
315  Other / Meta / Digital Goods -> Invites & Accounts on: February 07, 2017, 02:41:47 AM
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?
316  Other / Meta / Suggestions for 200th ad round? on: February 07, 2017, 12:45:05 AM
The 200th forum ad round will be in about a week. Normally I do some something on significant numbers like this. Any suggestions?
317  Economy / Auctions / Re: Advertise on this forum - Round 199 on: February 07, 2017, 12:43:51 AM
P.S. I need to think of some special rules for the 200th round's auction, so there won't be a new auction for a couple days.
318  Economy / Auctions / Re: Advertise on this forum - Round 199 on: February 07, 2017, 12:30:18 AM

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
319  Economy / Trading Discussion / Idea for a method of more privately buying/selling BTC on: February 02, 2017, 06:51:07 PM
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.
320  Economy / Services / Re: [BOUNTY 0.25 BTC] [HTML/CSS] Fix for the forum ad area on: January 30, 2017, 07:07:22 PM
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.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 [16] 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 ... 346 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!