Even if its 1000 BTC - 0% Donation and took me 5 mins to set it up, I am completely in my rights to do this, there are no gimicks or tricks, If you dont agree with the Raffle dont participate, very simple. Two questions:
Grue: Are you familiar with Raffles? This raffle has the best odds of any I have ever seen
No, not really, but i did remember the BFL raffle https://bitcointalk.org/index.php?topic=67937.0 had much better odds. Also no disrespect but I have to ask, Do you really not have anything better to do than troll my raffle? Its very simple for 1 Bitcoin you get a good chance to win a very high end graphics card and donate a little something to the forum at the same time. If you think I am doing something wrong go start your own raffle. No, i was simply pointing out that gigavps' calculation was flawed. i know that 20% of this is going to the forum, but that is dwarfed by the 42% that is given to the operator. mathematically, it's obviously better to simply donate to the forum directly. even from a purely "for fun" perspective, you could gamble at other places that have much lower margins.
|
|
|
I think 300 bitcoins for 100bitcoin prize is too large cut.
Let's do some math. 300 BTC - 20% donation (60 BTC) - cost of prize (112 BTC) == 128 BTC profit (42%) This does not include his time to make the site, setup bit-pay, deal with this thread, pick a winner, etc. So let's say that's 30 hours. 128BTC / 30 hours of work == 4.267 BTC per hour (~$20 / hr) If you think it is wrong for someone to make $20/hr in BTC to let forum members have a fun and a chance of winning a pretty cool prize, maybe you should try to do better while taking a smaller cut. that's assuming that he'll never be able to use his scripts again, which is clearly not true. and 30 hours to setup a site (with bugs) is clearly an overestimate.
|
|
|
Total BTC generated/day: 0.2 Total BTC sold/day: 0 Total BTC held/day: 0.2
|
|
|
I would like to make a small feature request if it's not going to cause too much trouble: the ability to delete pools/workers
|
|
|
I imagine the "super" cards will be in the range of $20+. That's probably fine for elite users and the security-conscious. It will be competing as a more secure alternative to smart phones. So it's in a niche market anyways. For regular smart cards, maybe they could be paired with some type of online service that keeps an eye on merchants and perhaps validates transactions based on buying patterns. At the very least, it would be nice to receive some type of statement at the end of the month to be able to detect fraud. Otherwise, with nothing but the blockchain to go by, it would be basically impossible to know whether your grocer has a hacked POS terminal that is ripping you off. So, just from what we've come up with so far, our universal POS terminal is looking at supporting: - Smart phones via QR code / NFC
- Super cards via contact (/ contactless?)
- Smart cards via contact
- Online balance service
- Online transaction verification service
- Online "lite client" service?
Then on top of that add interfacing with the merchant's accounting system. And besides magstripe and contact/contactless credit cards, you're competing with Paypal and Dwolla and that new Canadian Mint thing. It's likely that none of those will cooperate to share hardware. the cheapest & easiest to implement would be an android/ios client. nearly everyone has a cell phone, and if you're just signing transactions, you don't even need a data plan. however, this will require some way to transfer the signed transaction back to the POS terminal (maybe camera to scan QR code?), so you're looking at additional costs for the merchant.
|
|
|
and do you realize that my attack simply involves making a second transaction, which for all intents and purposes is identical to a normal transaction? until there's a way to prevent the attack, i don't see any point in discussing merchant adoption of an insecure system.
grue, I understand that your attack has relevance to standard smart cards. How much relevance, I'm not sure, since those basically require you to trust the POS terminal regardless. But I want you to look again at the hardware I'm proposing be used, and to think about the process flow: - The terminal sends the transaction amount to the smart card.
- The transaction amount is displayed on the smart card.
- The user presses the button on the smart card to verify the amount.
- The smart card creates and signs the transaction.
http://www.nidsecurity.com/products/106-details.jpgThere is no way to create multiple transactions without consent. There is no way to create transactions with the wrong amount without consent. No sensitive information is transferred to the terminal. All transactions are created on the card itself using Bitcoin keys that never leave the card. I see your point now, thanks for clarifying it.
|
|
|
grue, do you understand that the entire point of a smart card is that the private key never leaves the card?
and do you realize that my attack simply involves making a second transaction, which for all intents and purposes is identical to a normal transaction? until there's a way to prevent the attack, i don't see any point in discussing merchant adoption of an insecure system.
|
|
|
no, i'm arguing about how secure a smartcard system (in general) can be. it's very hard to keep your keys secure if the terminal that you're using can't be trusted. as long as the interface between the card and the user isn't protected, there will always be a risk of a man-in-the-middle attack. if you have a solution to prevent the attack i mentioned earlier, i will be glad to hear it. One of these measures is to house your security information on a computer chip within the card as opposed to displaying it on the card. Another is a unique display window that reveals a security code necessary to complete a transaction. Each code can only be used once, so even if your card information were stolen, a thief would be unable to effect a transaction without having physical possession of the card and its security code. This window can also display account information such as your last transaction, your balance, how much you have spent this month, even messages from your bank. too bad i got both
|
|
|
I was unable to download this from any of the FOUR sites linked.. can someone provide a (private) plain HTTP link or torrent to this? I can mirror it once I have a copy.
the rapidshare mirror works fine for me
|
|
|
DO NOT TRADE
This is in direct violation of Steam's user agreement, and is furthermore extremely risky. The seller can at any time after the sale reclaim the account by contacting Steam Support with CD-keys or credit card numbers associated with the account.
No reputation as well.
DO NOT TRADE
this
|
|
|
If you can install an overlay between the keys and the actual circuit board, you can easily capture the pin, and launch a replay attack.
Well... can't the card be locked immediately after a purchase (say 30-90 s). but then the smart card will need an internal power source, which will definitely not fit in a card. If it does what stops anyone from hacking any VISA card in the world?
visa/mastercard is supposedly secure because POS terminals that can process EMV transactions have to be tamper evident (sealed with sticker), and can't have removable faceplates, which should remove the risk of physical keylogging attacks. maximum rage
1. get yourself a bitcoin POS terminal 2. open it up, and place a circuit that monitors keypad input (remember, this is inside the unit, so 99.9% of the users won't notice) 3. get yourself an arduino and program it so it can do everything a normal POS terminal can do 4. hook the keylogging circuit to the arduino 5. close the entire unit, and make everything look legit 6. place it in your store 7. wait for a customer to buy something 8. the payment gets processed as usual, but now the merchant can charge the customer again, because the card is still inside, and the pin has been logged.
|
|
|
assuming you can even implement a protocol that doesn't allow the private keys to be leaked
A lot of smartcard apps are poorly designed. But it isn't black magic or anything. It's definitely doable. Look at the satellite TV access cards. They can be reverse engineered, if you have access to the card itself and a scanning electron microscope. if you can install an overlay between the keys and the actual circuit board, you can easily capture the pin, and launch a replay attack. a much better way is to have a portable wallet that "pays" a merchant by transferring a signed tx, which the merchant can verify and broadcast.
|
|
|
assuming you can even implement a protocol that doesn't allow the private keys to be leaked, you'll also need some sort of way to prevent unscrupulous merchants from skimming the card using a tampered terminal. related vid: http://www.youtube.com/watch?v=JABJlvrZWbY
|
|
|
I would love to code it myself, but I don't understand Bitcoin's code well enough yet. First I'd like to implement a simple python client so I can really understand all the dirty details, and then maybe I'd be able to do something like that.
there's your problem. the only full bitcoin client (correct me if i'm wrong) is in c++.
|
|
|
Status Hopping Detected! is there any actual downsides to this? i'm just using this as a backup pool for gpumax
|
|
|
i guess this won't be very useful for me (check avatar) but i'll give you a free bump
|
|
|
The main site's certificate is signed by Verisign, but the socket connection for displaying the current price is served with a StartSSL certificate. Likely, the StartSSL root cert isn't trusted on your device.
but it says that the problem cert is issued by verisign
|
|
|
Can't read anything
HTTP Status 503 - 503 Server temporarily busy, please try again in a short while
works fine for me
|
|
|
what you need is a design-my-coin or design-my-block-chain tool;
download, input a few parameters, build, run, & profit.
It's so easy, even a caveman can do it.
or use testnet-in-a-box
|
|
|
|