Merchant adoption is not here, nor is merchant adoption present in any significant way in Bitcoin.
Let me judge if I find the bitcoin merchant adoption significant or not on my own. Going by the numbers and big names I could list some data but I was asking about the data for ripple. Is there any merchant where I could pay using ripple? If yes, is there tens or millions? Is there one in my city?
|
|
|
Ripplecharts.com shows the total number of wallets.
Is there historical data somewhere to be found, too? Is it centralized or are there several wallets to be watched and hard to count as in bitcoin?
|
|
|
crypto coin tables gets a regular visit from me and today i noticed how ripple is doing totally exceptionally well. so well that i start wondering if there might actually be anything in terms of merchant adoption. is there a coinmap.org for ripple? is there a list of accepting merchants available somewhere? is there some hint on the number of users like the blockchain.info/wallet?
|
|
|
So over the day I came to the assumption that BIP70 does allow to send a payment request with actual addresses but not with extended public keys, so I will have to go with many simple addresses rather than with a generator?
|
|
|
I'm implementing a (most likely soon to be open source) product that already kind of works with normal addresses but I would really want it to interact with BIP32 extended public keys coming from users' phones, most likely via a BIP70 payment request.
Is there any mobile or web wallet that does generate these requests or do they all merely understand and react to them?
In the absence of NFC (yeah, most phones don't have NFC still) a QR-Code representation would be cool but BIP72 talks about a link that's being communicated. In a server-less scenario that is kind of a problem and QR-codes (yeah, they must die but for now lets assume they will be around and dominant for another 5 years) can store by far more information than is necessary for an extended public key. Is there a standard and how would data for such a QR look like? Is BIP70 as maybe BASE64-encoded QR anywhere close to being a standard?
Thank you in advance for any hints.
|
|
|
Who holds the private keys? In Mycelium, the user does according to the source code but with any binary from google play, the user has to trust the developer with his funds so for me the first question would be, who is the developer and then who holds the keys.
|
|
|
are people still trying to act smart and say its a risk without actually trying to test it out.
go on testnet and try to freeze their blockchain. or try it on a near dead altcoin (theres loads of them that are clones of bitcoin)
On testnet it would probably not work as the monetary incentives are not what they are on a real chain. Those alt-chain-scams are not as competitive as bitcoin neither. I bet many mine their alts just to point to the high hash rate it still has.
|
|
|
I think definiting a maximum fee of say 1 BTC would make sense for a future Bitcoin version.
Limiting the fee would not work as you would have to limiti the total fee spendable by coinbase as nobody could limit me from broadcasting 200 tx with 1BTC each.
|
|
|
Rassah I agree that imsi catchers are an issue for privacy but I don't agree that this card has to have the same problems. If I pay with it in a store, the store can assign it a customer id and regardless of me giving my name or not, it now can track me through the shop for all eternity as customer #42, link that to photos and eventlually retroactively to my name if ever I give it, only if the card keeps its ID. If the card identifies differently every day and the wallet is an HD wallet, I don't see such issues.
Sure, to prevent certain kinds of DOS attacks, you can't allow to change the ID at any speed, but once per day would be nice for the merchant, as it could still track overall user movements in his shop but it would also be nice for the user as it has some privacy when coming back tomorrow.
|
|
|
Is something broken? Litecoin works, but Bitcoin doesn't.
works fine for me Guess it's just the long load time. Here the json is downloaded at the 7s mark. Not sure how much processing adds to this. Given download starts at 4s, it would maybe be worth adding it somehow differently, so it gets loaded 4s earlier or start working with some model that scales better by having maybe a header file with just the totals per country so you get something quickly.
|
|
|
Bitcoinbikers is either trolling or scamming. Seen this while doing a paste. Sure.
|
|
|
On 06/10/2014 08:43 p.m., Tom Harding wrote: PS: Using so many acronyms makes arguments much more concise, but suggest we should have all the attack terminology described in a single "Bitcoin Security Wiki"...
… please. CHAKIDO is missing in my vocabulary. But it seams to be what I asked for over at reddit.
|
|
|
Interesting attack indeed but h4xx0r who did you quote with the idea of giving to the next miner a share of your coinbase tx? It's trivial to give to the next miner outside the coinbase transaction by sending the reward as a transaction using one of the current inputs. Sure, then you have to scrape the bitcoins from elsewhere. To recap the attack in laymen's terms: If somebody paid 10,000BTC in transaction fees, miners would not care about block rewards for the next 10,000/25=400 blocks. Any miner that thinks it could outrun the biggest other miner would try to do so. If there is a draw between the top miners, such a battle could take a long time. If the top miners hold 10% of the mining power, they might try even when the other had a head start and was slowly building a chain that's growing faster than the own chain as they could still call their friends of other pools to team up catch that guy, essentially to the point where all miners took one side or the other and weaker group gives up. During such an episode, massive re-orgs would happen, clients would act strangely, Finney attacks would be slightly easier etc. and we would have a slightly higher level of drama. And we will never know who sponsored that drama but it would not be a cheap endeavor. It's an interesting math problem. If you have 51% of the global hash power, then it is generally in your favor financially to mine only on top of your own blocks, ignoring all other blocks. As your hash power drops below 51% it begins to become beneficial to build on to of the most recent block, due to the cost associated with the orphan risk. However, with 49% of the hash power, it would probably be beneficial ignore any block that has a larger than average block reward. The lower your percentage of the hash power, the higher value a block reward must be to overcome the cost associated with the orphan risk. Assuming for the sake of calculation that all solved blocks are instantaneously known by all miners, and that there are never any splits caused by two or more miners simultaneously solving the current block... Is there a formula that can indicate for every percentage of global hash power how much higher than the average block reward would be necessary to result in a positive expectation for ignoring the most recently solved block and continuing to attempt to mine it one's self? Anything over 50% requires a no increase above average reward to result in positive expectation. As you approach 0% the required increase above average reward approaches infinity. What does the curve look like between those two extremes? The assumption of selfish mining and total transparency of mining power among all the competition is essential here. If I have 1/n-th of the network, just like all the competing, evil miners I would find every n-th block, gaining every n-th block reward if we play nicely. If we don't I might not get it in the end, so I have an incentive to help punishing others that don't play nicely, but without crazy fees, there is little incentive to build on top of one block rather than another, so it works. With a big treasure trove setup for the winner, those evil miners can try and if all factors are known, you can't win unless you have 51%. Imagine you have 49% and set out to try this. The others know they have 51% united but less than 49% each for themselves. They would go with the first block regardless where it came from as they don't go for cheater mode. They would further assume that any fork mining the treasure trove to another address to originate from the only candidate that might try foul play and would stick to the old chain, knowing that they can win. Unfortunately in the real world they can't know if some other miner supports Mr. 49% just this one time, so they might be in for some long orphan chain, so I doubt there is a formula as the biggest selfish miner always wins against selfish miners, while non-selfish miners are meant to protect the network. I guess if this ever would be a problem once, in the future miners would just put a bait into the tx pool in form of some 20% of the received fees and nobody would attempt to pull this off. We could just as well discuss the problem of somebody paying a pool for not mining as it would have the same slowing effects as this attack if the economics are right.
|
|
|
Interesting attack indeed but h4xx0r who did you quote with the idea of giving to the next miner a share of your coinbase tx? It's trivial to give to the next miner outside the coinbase transaction by sending the reward as a transaction using one of the current inputs. Sure, then you have to scrape the bitcoins from elsewhere. To recap the attack in laymen's terms: If somebody paid 10,000BTC in transaction fees, miners would not care about block rewards for the next 10,000/25=400 blocks. Any miner that thinks it could outrun the biggest other miner would try to do so. If there is a draw between the top miners, such a battle could take a long time. If the top miners hold 10% of the mining power, they might try even when the other had a head start and was slowly building a chain that's growing faster than the own chain as they could still call their friends of other pools to team up catch that guy, essentially to the point where all miners took one side or the other and the weaker group gives up. Also the attack does only work if the biggest selfish miner is bigger than the total of his run-up competitor with all non-selfish miners, so it assumes a pretty corrupt mining landscape. The attack's effects: During such an episode, massive re-orgs would happen, clients would act strangely, Finney attacks would be slightly easier etc. and we would have a slightly higher level of drama. And we will never know who sponsored that drama but it would not be a cheap endeavor.
|
|
|
how is litecoin (and other alts) doing? check http://crypto-coins-table.com . here the performance is measured relative to bitcoin, so the one day change of most alts is red right now.
|
|
|
It would be nice if I could receive e-mails about bitcoincard. Do you have a newsletter?
No. We just make announcements here and Reddit, and on our mycelium.com website. I'm sure you will hear of it on all channels when this nice little gadget gets released.
|
|
|
If I had stolen his wallet and "proved" to you today that I'm SpartacusSatoshi, how would that be a proof? As long as the real Satoshi doesn't start arguing against that, the signature proof would serve nothing.
|
|
|
I think we're seeing some people submitting lots of tiny, trivial commits -- perhaps because they get more of the tipping pie.
I'm not sure how to combat that bad incentive....
Small commits are not always bad. Sure, fixing the code formatting one line at a time, putting each in a separate commit is improving the code but wasting much time of those reviewing it. Incentivizing to group code formatting fixes with functional changes is also bad as "fixed formatting" and "fixed bug" should be two commits. Key should be to find a metric a computer understands, that is not too far from the goal of having a great product. Do you know the Continous Integration Game? They put some serious thoughts on how to measure code in an automated way that is way better than just by commit (badbad) or by LOC (lines of code changed in a commit would only incentivize many commits if the developer edited the same lines multiple times) which would be the next best thing. The idea would be to hook Tip4Commit not into the version control but into the CI and to have the maintainer define rules. Down side is that a CI is just one extra thing that is no high on the list of many projects.
|
|
|
Your crash page (This exception has been logged with id 6jeiapmm6) and the associated favicon tells me you are using playframework. I love it The price is insane! 10% markup? WTF? Before, I could top up at 0% if I picked the $30 option. With a 10% markup I'd love to see a $1 option as I will certainly only use it in emergency situations and not to regularly top up my plan. And, yeah, in this emergency situation now I was glad to see you back in business in Chile at all but ran into above mentioned Exception.
|
|
|
Is that something agreed upon?
Yes, it is. http://wiki.openstreetmap.org/wiki/Bitcoin[...] currency:XBT=yes [...]
[...] vending=bitcoin [...]
Am I correct that either way they do not show up in CoinMap? currency:XBT=yes works, for CoinMap. Ciao! If this is so, it should maybe be told more people as there is not many ATMs on coinmap, right?
|
|
|
|