How does that affect me one iota if I am just using Ripple to move my CNY from BitcoinCN into USD at Bitstamp?
Well don't you need XRP's to do that? So basically what happens is that the currency needed to use Ripple is mainly in the hands of it's developers and everyone else has to pay bigger and bigger amounts for it, eventually making the developers mega-billionares. No thanks. I don't personally need XRPs to do that, but Ripple will cause them to be used when it executes both sides of the transaction. Do I care if some small amount of XRPs used in the transaction goes to those holding XRPs? Nope, .... what I care about is the ability and cost for me to move CNY at BitcoinCN into USD at Bitstamp. And until some other solution to this problem arises (i.e., don't expect Dwolla, OKPay or Liberty Reserve to become widely uses), Ripple provides the best solution that is in operation today. That's possibly the best case ripple has today, but all we need is a coinbase.cn or equivalent to solve this problem without xrp. It's actually surprising this is taking so long with at least a 1% xbt to fiat transaction fee on the table in virtually every country not serviced by something similar to coinbase. |
|
|
|
C'mon let's not rain on robocoin's parade by letting this thread denigrate into yet another ripple smackdown.  There is one very simple reason that any vc or marketing specialist will understand, why ripple can never succeed (at least in its current form): It has no elevator pitch. And probably can never have one due to its inherent complexity. |
|
|
|
The day 2 Robocoin ATM turnover in BTC was greater than the whole month of October for the Ripple system.
+1 That really puts the uphill battle that ripple faces in perspective. It's really difficult to see how they can survive when their own employees struggle even to explain what ripple is. |
|
|
|
|
With the approx. 7% buy/sell rate premium the machine should be paying for itself quickly... that's roughly $700 in fees today alone.
This should get the attention of the private ATM market, where $70 in fees is probably a good day.
|
|
|
|
|
Eventually bitcoin will regulate government, not the other way around. It is inevitable.
|
|
|
|
|
We've seen this movie before: email, www, etc.
Often even the major players that should, just don't 'get it'. Microsoft had to fight hard (and dirty) to make IE relevant when they finally realized the WWW and HTML wasn't just some fad.
|
|
|
|
...
Ok, I'll try to summarize what the payment protocol is trying to solve (at least, the way I see it, correct me if I'm wrong).
Right now, when you want to buy alpaca socks, you go to the website, click on the product, click pay and then you're presented with a QR code or a link that you can use to make a payment to the merchant.
There are two problems with this.
1) There's no telling if that QR code or link isn't modified en route to your computer (man in the middle attack);
2) Once the payment has been made, there's no proof that you actually made that purchase.
The first one isn't even a truly big issue. Most likely the webpage you're visiting is already running over SSL. The second one however, proof of purchase, is a big one. If you want to file a dispute (and would want to take the merchant to small claims court), then you want to show the judge some kind of receipt. That's exactly what the payment protocol provides. A signed payment request (tied to the merchant's identity), containing the payment request and the address(es) that you sent your payment to.
That's the gist of it. It has other features, like you can supply a refund address when you make your payment and you optionally get an acknowledgement (but this is optional).
At no point in this communication is the customer required to identify himself. (other than the practical need to supply a shipment address for the product of course).
I'm sure there are more things possible, but that's in layman's terms what it does.
In two words: Consumer protection.
Finally, a rational real-world business use case for this protocol! This will clear the courts of frivolous alpaca socks lawsuits. You know, the ones where someone buys alpaca socks, gets scammed by a man-in-the-middle attack, and then sues the online store in small claims court when the site claims they never received payment. Now we'll finally have a cryptographically-signed receipt so that we can subpoena the CA-certificate issuer and get to the bottom of the whole mess as soon as possible. (sorry Riplin, couldn't resist. It is a good summary of the protocol though!) |
|
|
|
I think the US has already tried a similar approach: This is the first generation that will be less educated than their parents. How's that working out? ... at the same time China has 10's of millions of engineers graduating over the coming decade. This may not end well. |
|
|
|
|
From what I've seen there's no requirement to use the new protocol, and even when using them the use of CA certificates for signing is optional anyway, so some of the concerns being discussed here might not be a real problem.
Some of us do however have an issue with introducing third-party support/reliance of any kind into a system that was explicitly designed to be free of any centralized dependencies.
Only time will tell if anyone outside of a few payment providers, etc. actually use the protocol, but it could eventually evolve into something useful, with or without CA support. The core devs deserve credit for at least attempting to add this functionality, there's always bound to be some push back regarding feature implementation.
|
|
|
|
|
I tend to agree with the general concensus on the other thread running here somewhere: That this sort of functionality should be added as a vendor-neutral API interface, rather than being hard-coded into bitcoinQT, which should remain free of third party dependencies/support.
With full respect to the coredev team, this "upgrade" to bitcoinQT seems mostly like a solution without a problem, and not a really great one at that.
BIP38 is an example of a useful proposal that's already well tested and providing real security for many users today (off line storage, etc) why not implement that?
|
|
|
|
|
It would be very surprising if any card even remotely linked to XBT/BTC could remain part of any existing bank/credit card network for very long. We've already seen similar attempts that were shut down before they could even launch.
It's probably the easiest tool banks have to suppress bitcoin adoption. There's no way they'll allow bitcoin to gain traction using their infrastructure.
|
|
|
|
Please don't go inventing your own cryptography when it can be avoided. Scrypt did the work to write up an extensive analysis of their effort, and it was reviewed by many people at great cost. And even then the result has not been totally criticism free ( http://eprint.iacr.org/2013/525). I understand that new crypto has to go through a complicated vetting process to be trusted, and there are good reasons for this. I am just curious as to why something simpler was not settled on in this case. Unnecessary complexity is not our friend. Scrypt can be resource intensive and slow, and can appear to have unnecessary complexity, but the algorithm's slow execution speed and extensive resource requirement is actually a feature: It's far more difficult to attempt 100K password hashes in a brute force attack if each one takes 3.5s than if each one takes 3.5ms. If you need speed and resource efficiency, scrypt is probably not your first choice anyway. |
|
|
|
...
My takeaway here is that it is so simple to scam people who don't wait for confirmations and don't have time to verify IDs that Bitcoin can't work in the long run as a point of sale payment method in its current form unless businesses are checking IDs. I was hoping that 0-confirmation doublespends were complex enough to cost the attacker ~$50 or more each time so that small transactions could be more frictionless. Even if a coffee isn't that expensive, if people can use DoubleSpendQT at their local coffeeshop and get a free coffee half the time every time they buy coffee, it seems like a lot of people would do so.
A more accurate takeaway would be that a successful double-spend in an retail POS environment would be an extremely unlikely event, probably on the same order of probability as having the power go out in the middle of a credit card transaction, or being struck by lightning on the way to the bank with your daily deposit. Despite the numerous theoretical possibilities some of us have discussed for years now, the advent and success of bitcoin payment processors have provided some basis for a 'reality check' on the true risks, real or imagined, of accepting bitcoin in a coffee shop, etc. As it turns out, most payment providers are comfortable charging a maximum transaction processing fee of about 1% (Coinbase, BitPay, etc) while accepting liability for double spends, etc. From that, it could be inferred that the real-world transaction losses incl. 'race' double spends, Finney attacks, vector76 attacks, etc. must all amount to somewhat less than 1% of transaction volume. In other words, almost certainly less than "losses" with regular retail credit cards transactions, which are guaranteed to be at least 3-5% in fees alone. In fact, BitPay has previously stated publicly that they have never seen a double-spend in any of their transactions. As of Sept. 2013 they have transacted over USD $30M (in bitcoin). In other words, as a retailer, I wouldn't lose much sleep over it, at least until the facts suggest otherwise. You're far more likely to have someone pass you a fake $20 bill than you are to lose $2 on a double spend for a coffee. |
|
|
|
...
Only someone with my Trezor could create a valid signature. It allows a lot of cool uses where no one can pretend to be you without the actual hardware!
Ummm.. yes. That's the problem, exactly. Passwords, 2-factor auth, could all be a thing in the past! The Trezor keeps the private key hidden and secure. As long as I keep the device safe, my identity is safe. And for the online world that is a VERY exciting thing!
... that's basically advocating a return to 1-factor verification (using a Trezor instead of a password). There may be a lot of great uses for a Trezor but that's not going to be one of them! Don't get me wrong - the Trezor is a great innovation for bitcoin, with many other potential applications, but hardware signing has been tested, used and mostly abandoned for online banking over the past two decades (crypto-boxes, smartcards, etc.). Just saving you some time. |
|
|
|
YubiKeys are JUST for securing an online account. A Trezor (or Bitcoin client) could act as an identity in of itself! It's not 2-factor authentication but a single source of authentication that can be identified and tied to a Bitcoin public key.
A Yubikey has a unique, singular identity too (one key can be used on any number of sites) The real distinction being only that Yubico (sweden) is the central "identity verification server", whereas with Trezor it could verify against the blockchain, which may have a few advantages. (The 'off-label' use of the blockchain for verifying ID etc isn't really that new). The problem is that if someone steals your Trezor (or YubiKey) then it's really a distinction without a difference. Back in the early days of web based banking (very early, like "Netscape" early) banks provided hardware crypto boxes with a keypad and LCD, conceptually not unlike a Trezor, except USB wasn't invented yet.  They used a challenge-response model, where the box signed a numerical "message" that was provided, and you typed the result back into your browser. Same thing there. Just too cumbersome and it was soon abandoned with the advent of SSL, etc. 2-factor verification has only relatively recently made a comeback for widespread use. It's surprising that people still believe SSL provides any privacy at all considering recent revelations by Ladar Levison (Lavabit founder), Mr. Snowden etc. ALL SSL communication should be considered a 3-way conversation (as in you, me and the [insert 3-letter agency of your choice]). It may be "secure" but it's certainly not private. |
|
|
|
Trezor is at heart just a secure display with a couple of buttons and a small CPU. Such a thing has massive applications in all kinds of areas outside of Bitcoin. If they can scale up and get the costs down, stick and slush could build an decent sized business just selling these gadgets to businesses that want strong authorization of certain actions. Any company that currently uses 2-factor authentication for logging in could potentially benefit from the upgrade - including banks!
I think it'd make sense to pursue such markets, even though they aren't Bitcoin related. The money made from them can always be reinvested into other Bitcoin related research, and making the rest of the world more secure at the same time is a clear win for humanity.
There are probably many specialty crypto applications where Trezor would excel, but for 2-factor Yubikey pretty much owns that space already. Tough to compete with a $2 (cost) USB plug. Yubico has shipped millions of YubiKeys to more than 40,000 customers in 120 countries around the world..
http://www.yubico.com/about/reference-customers/ |
|
|
|
So much for section 10 of the white paper. 10. Privacy The traditional banking model achieves a level of privacy by limiting access to information to the parties involved and the trusted third party. The necessity to announce all transactions publicly precludes this method, but privacy can still be maintained by breaking the flow of information in
another place: by keeping public keys anonymous. The public can see that someone is sending an amount to someone else, but without information linking the transaction to anyone. This is similar to the level of information released by stock exchanges, where the time and size of individual trades, the "tape", is made public, but without telling who the parties were. As an additional firewall, a new key pair should be used for each transaction to keep them from being linked to a common owner. Some linking is still unavoidable with multi-input transactions, which necessarily reveal that their inputs were owned by the same owner. The risk is that if the owner of a key is revealed, linking could reveal other transactions that belonged to the same owner. http://bitcoin.org/bitcoin.pdf^ +1 Introducing a trusted third party (eg. CA) into a system which was created explicitly to not require one seems intuitively wrong on many levels. An API supporting external applications to handle this sort of tag-on feature would be a more elegant solution than shoe-horning them into the actual client. Same with Trezor support etc... They may be useful for some but they should not bloat the client unnecessarily. BIP 38 is a good example of what should be included in the client. It's already in widespread use (for encrypted off-line storage, etc) and would actually be useful for most users. |
|
|
|
OK. So its been over a year. How is this working out?
"Coinbase Wants to Be the PayPal of Internet"
They're basically there, or at least well on their way. They've attracted the largest single VC funding of any bitcoin startup ($5M). Coinbase's first mover advantage is very similar to that Paypal had in its early days - right before their many competitors threw in the towel. It's tough to compete with free. Coinbase has a zero-fee merchant sign-on program currently underway (first $1M in bitcoin sales at no commission). For end users, there really no faster or lower-fee (1%) way to buy or sell bitcoin, all you need is a bank account. Why anyone in the US would still use MtGox for the occasional buy/sell is difficult to understand. Definitely the best place to send anyone new to bitcoin. |
|
|
|
Remember the Mint-Chip challenge? They asked the question: "What would mintchip be useful for?" The #1 answer was "to buy bitcoin". So they took it down and went with another "winner". Yes, that was priceless... There's no way this project will fly in a post-Snowden world. One of the developers - or at least someone purporting to be - claimed this was engineered with full government backdoor access. |
|
|
|
|
Show Posts
