Bitcoin Forum
May 27, 2024, 05:19:27 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  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 ... 110 »
101  Alternate cryptocurrencies / Altcoin Discussion / Re: With the current ripple bubble(?) I wonder what one can do with it on: November 27, 2014, 08:41:25 PM
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?
102  Alternate cryptocurrencies / Altcoin Discussion / Re: With the current ripple bubble(?) I wonder what one can do with it on: November 27, 2014, 08:38:53 PM
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?
103  Alternate cryptocurrencies / Altcoin Discussion / With the current ripple bubble(?) I wonder what one can do with it on: November 27, 2014, 07:37:19 PM
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?
104  Bitcoin / Development & Technical Discussion / Re: Mobile wallets with BIP70 extended public keys on: November 27, 2014, 07:46:26 AM
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?
105  Bitcoin / Development & Technical Discussion / Mobile wallets with BIP70 extended public keys on: November 26, 2014, 07:43:55 PM
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.
106  Bitcoin / Bitcoin Discussion / Re: Best Bitcoin Android apps and widgets on: November 18, 2014, 08:43:41 PM
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.
107  Bitcoin / Bitcoin Discussion / Re: F.R.O.N.T. Attack Vector and What the Bitcoin Devs are doing to prevent it. on: October 19, 2014, 04:07:24 AM
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.
108  Bitcoin / Bitcoin Discussion / Re: F.R.O.N.T. Attack Vector and What the Bitcoin Devs are doing to prevent it. on: October 19, 2014, 04:05:41 AM
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.
109  Bitcoin / Bitcoin Discussion / Re: bitcoincard.org on: October 15, 2014, 04:15:41 PM
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.
110  Bitcoin / Project Development / Re: [ANN] CoinMap - Map showing places where Bitcoin is accepted on: October 15, 2014, 02:51:22 AM

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.
111  Bitcoin / Bitcoin Discussion / Re: Satoshi Nakamoto post on pastebin? on: October 14, 2014, 02:24:57 AM
Bitcoinbikers is either trolling or scamming. Seen this while doing a paste. Sure.

112  Bitcoin / Bitcoin Discussion / Re: F.R.O.N.T. Attack Vector and What the Bitcoin Devs are doing to prevent it. on: October 07, 2014, 10:50:06 PM
Quote
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. Sad But it seams to be what I asked for over at reddit.
113  Bitcoin / Bitcoin Discussion / Re: F.R.O.N.T. Attack Vector and What the Bitcoin Devs are doing to prevent it. on: October 07, 2014, 04:49:28 AM
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 Wink 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.
114  Bitcoin / Bitcoin Discussion / Re: F.R.O.N.T. Attack Vector and What the Bitcoin Devs are doing to prevent it. on: October 07, 2014, 03:55:05 AM
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 Wink but it would not be a cheap endeavor.
115  Bitcoin / Bitcoin Discussion / Re: BREAKING: PAYPAL PARTNERS WITH BITPAY ET AL on: September 23, 2014, 07:34:05 PM
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.
116  Bitcoin / Bitcoin Discussion / Re: bitcoincard.org on: September 17, 2014, 02:03:47 AM
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.
117  Bitcoin / Bitcoin Discussion / Re: What if someone claims to be Satoshi Nakamoto? on: September 10, 2014, 03:47:48 AM
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.
118  Economy / Service Announcements / Re: [ANN] Tip4Commit.com - support opensource projects, contribute and earn bitcoins on: September 10, 2014, 03:35:05 AM
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.
119  Economy / Service Discussion / Re: piiko.com … recharge your mobile phone … gone? :( on: September 07, 2014, 05:25:54 PM
Your crash page (This exception has been logged with id 6jeiapmm6) and the associated favicon tells me you are using playframework. I love it Smiley

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. Sad
120  Bitcoin / Project Development / Re: [ANN] CoinMap - Map showing places where Bitcoin is accepted on: September 07, 2014, 03:10:46 AM
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?
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 ... 110 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!