|
Yes, but with Apache and Python, it was the people who were doing the engineering writing further proposals.
|
|
|
|
Sure, just give me a couple examples so I can just mirror some API you're already being fed.
mtgox has: * http://mtgox.com/code/ticker.php * http://mtgox.com/code/data/getTrades.phpbitcoinmarket has the previously mentioned real-time API, and also * https://www.bitcoinmarket.com/bitcoin/fxchange.quote.json * https://www.bitcoinmarket.com/bitcoin/fxchange.quote.json.alt * https://www.bitcoinmarket.com/quotes/offers/bids/ * https://www.bitcoinmarket.com/quotes/offers/asks/ * https://www.bitcoinmarket.com/quotes/trades/The ideal ticker would have, for each currency pair * currency pair * last-traded price * last-traded datetime * volume, last 24h * highest bid * lowest ask * open price, set once every 24h at "beginning of the day" (== midnight UTC, probably, if you are open 24/7) * previous close price (might be same as open price, if you are 24h and have no dark pools etc.) * highest price since "beginning of the day" * lowest price of "beginning of the day" The first six are provided by all markets and are IMHO "required." Trade data is generally * currency pair * price * datetime * quantity traded but feel free to include anything else that does not compromise the privacy of your users. Returning data in JSON format seems to be de facto bitcoin community consensus (only BCM is an outlier here, and only for their trade data; BCM's tickers are JSON). I'll look into that, it has its official github issue  Not sure how to parse that... is your exchange's source code published at github? If not, what's your price for open sourcing? Thanks for opening another exchange! bitcoin needs more competition in this area. |
|
|
|
I'd rather not introduce Yet Another Place (we've already got these forums, IRC chat, and github) to talk about bitcoin development.
These two statements contradict each other, because github is Yet Another Place, too. I do not see any point in moving the discussion of some bitcoin changes to a special place outside the forum. Discuss changes on the forum just like we've always done, regardless of whether that change is a proposal, a patch, or a pull request. The forum is perfectly adequate for discussions. |
|
|
|
Instead of pledging small bounties for what is an important project, it might be a good idea if we setup a page on the wiki and begin documenting how such a site should look/function.
I agree on documenting things . Its not actually the site thats important its coming up with some sort of standard for future reference. I have another bounty for something similar which is a web based currency converter like you see at xe.com A current list of resources for people to use to build on top of would be helpful. I urge the exact opposite -- start coding first. If people start writing, then you wind up with a project where kiba, RHorning and other talkative types have a lot of input into something that few programmers are interested in coding. Absent a real bounty, that compensates real programmers at real market rates (100+ BTC/hour), you are looking at volunteer programmers working on their own inclination, on their own time, to produce something that interests them. A wiki document might be "interesting" reference material, but don't expect volunteer programmers to write code for a spec created out of thin air by non-programmers. The world is littered with useless, pie-in-the-sky specifications better suited for garbage pails. And those were written by engineers. Specifications written by management types that don't code are even worse. |
|
|
|
Supporting Pecunix GAU would be nice
Is there really that much demand for it ? Not as much as LRUSD, but there is a consistent level of demand. It's useful because, just like bitcoin, PGAU is not a fiat currency tied to a nation-state. And it's easy to implement in an automated fashion, once you support LR. GlobalDigitalPay is another easy one to support; GDP's API works like LR's API. GDP supports USD, EUR and GBP. Additionally, with my bitcoinwatch hat on, please publish - current "ticker" in JSON, showing last-traded price, current bid, current ask, volume for past 24 hours, etc.
- full data for each trade, in JSON format
And something like bitcoinmarket's real-time data service would be nice. I wrote some Perl to accomplish this, see http://yyz.us/bitcoin/bcast-README.txthttp://yyz.us/bitcoin/bcast-server.txthttp://yyz.us/bitcoin/bcast.txtor simply "telnet www.bitcoinmarket.com 27007" and add/remove a bid or ask on BCM to watch the real-time data stream. P.S. If you wanted to see your site's popularity skyrocket, permit trading between non-bitcoin currencies, such as GDP-USD / LR-USD, or GDP-EUR / LR-USD, or LR-USD / Pecunix GAU. |
|
|
|
Flood-fill scales in practice, because interested network parties keep upgrading to handle the load. DHT is pointless, as you could lose information to network partitions or simply if an unlucky set of participants disconnects.
Overall the current system is designed for Big Players With Capacity to survive on the P2P network long term. It is simply not meant for small players. Not really a good argument, why impose the need to keep up, if simple changes can lower the barrier? Remember that if we can think of it, others will too, if we don't implement it, others will. And if they do you can be sure they'll start a new block chain, eventually surpassing our community in size, because of the added flexibility, and thus making all our hard earned Bitcoins worth less. If you want to design an alternate bitcoin, hey, go for it. But what you're talking about isn't really bitcoin at that point. The current system is designed to devolve into (a) Large Mining Conglomerates, and (b) lightweight clients that simply "sip" the necessary parts of the block chain. Unfortunately we continue to await the development of the much anticipated "lightweight client" that will not need to receive every tranasaction and echo it, etc. satoshi added the "getheaders" network message recently in order to better support lightweight clients, which permits casual connectivity, pulling only the block headers needed since last connection. Which is basically the implementation of a 2 hierarchical system as proposed earlier. It is by no means the definitive solution to everything, since even the inner network will eventually become too busy to handle the message complexity. Do you have any hard data that even remotely backs up these "too busy" claims? One block header every 10 minutes remains fixed at ~80 bytes, regardless of 10 or 10,000,000 transactions per block. Lightweight clients only need block headers and transaction data directly relevant to their wallets, as the system is currently designed. Lightweight clients do not need to listen to, nor relay, all-network transactions and all-network completed blocks as do full nodes. I would rather we just remove the "fee for < 0.01 transactions" rule. If people want to spam, they can spam with 0.01 BTC transactions, and fill up the free-TX area in each block. Making everyone else pay? To be really resilient we have to make the network Dos proof, and while there is no definitive solution to this, we can make steps in the right direction. Define "DoS" proof, and then review how the current system works. People can DoS the tiny free TX area, and then they must start paying transaction fees. That's the system working as designed. TX fees make the system more expensive, as transaction rates increase, making DoS and spam more expensive, the more data sent. |
|
|
|
One of the very frequent questions I have to answer to is "how scalable is the Bitcoin network?" and my usual answer is that it isn't at all scalable. Simply the fact that every transaction is broadcast in a random fashion is incredibly wasteful. Were we to adopt a nicer system (pulling transactions only when a block is found, upstream aggregation, DHT style responsability sharing, ...) it would work so much nicer and would scale better.
Flood-fill scales in practice, because interested network parties keep upgrading to handle the load. DHT is pointless, as you could lose information to network partitions or simply if an unlucky set of participants disconnects. Overall the current system is designed for Big Players With Capacity to survive on the P2P network long term. It is simply not meant for small players. Unfortunately we continue to await the development of the much anticipated "lightweight client" that will not need to receive every tranasaction and echo it, etc. satoshi added the "getheaders" network message recently in order to better support lightweight clients, which permits casual connectivity, pulling only the block headers needed since last connection. I would rather we just remove the "fee for < 0.01 transactions" rule. If people want to spam, they can spam with 0.01 BTC transactions, and fill up the free-TX area in each block. |
|
|
|
After adding diagnostics to cpuminer, I have gotten several 'getwork' failures with HTTP status code '502' when connecting to your mining pool: [jgarzik@bd cpuminer]$ ./minerd --userpass user:pass --algo 4way --url http://mining.bitcoin.cz:8332 --quiet
1 miner threads started, using SHA256 '4way' algorithm.
PROOF OF WORK FOUND? submitting...
PROOF OF WORK RESULT: true (yay!!!)
HTTP request failed: The requested URL returned error: 502
json_rpc_call failed, retry after 30 seconds
PROOF OF WORK FOUND? submitting...
PROOF OF WORK RESULT: true (yay!!!)
PROOF OF WORK FOUND? submitting...
PROOF OF WORK RESULT: true (yay!!!)
PROOF OF WORK FOUND? submitting...
PROOF OF WORK RESULT: true (yay!!!)
PROOF OF WORK FOUND? submitting...
PROOF OF WORK RESULT: true (yay!!!)
PROOF OF WORK FOUND? submitting...
PROOF OF WORK RESULT: true (yay!!!)
PROOF OF WORK FOUND? submitting...
PROOF OF WORK RESULT: true (yay!!!)
PROOF OF WORK FOUND? submitting...
PROOF OF WORK RESULT: true (yay!!!)
PROOF OF WORK FOUND? submitting...
PROOF OF WORK RESULT: true (yay!!!)
PROOF OF WORK FOUND? submitting...
PROOF OF WORK RESULT: true (yay!!!)
PROOF OF WORK FOUND? submitting...
PROOF OF WORK RESULT: true (yay!!!)
PROOF OF WORK FOUND? submitting...
PROOF OF WORK RESULT: true (yay!!!)
PROOF OF WORK FOUND? submitting...
PROOF OF WORK RESULT: true (yay!!!)
PROOF OF WORK FOUND? submitting...
PROOF OF WORK RESULT: true (yay!!!)
PROOF OF WORK FOUND? submitting...
PROOF OF WORK RESULT: true (yay!!!)
PROOF OF WORK FOUND? submitting...
PROOF OF WORK RESULT: true (yay!!!)
PROOF OF WORK FOUND? submitting...
PROOF OF WORK RESULT: true (yay!!!)
PROOF OF WORK FOUND? submitting...
PROOF OF WORK RESULT: true (yay!!!)
HTTP request failed: The requested URL returned error: 502
json_rpc_call failed, retry after 30 seconds
PROOF OF WORK FOUND? submitting...
PROOF OF WORK RESULT: true (yay!!!)
PROOF OF WORK FOUND? submitting...
PROOF OF WORK RESULT: true (yay!!!)
PROOF OF WORK FOUND? submitting...
PROOF OF WORK RESULT: true (yay!!!)
PROOF OF WORK FOUND? submitting...
PROOF OF WORK RESULT: true (yay!!!)
PROOF OF WORK FOUND? submitting...
PROOF OF WORK RESULT: true (yay!!!)
PROOF OF WORK FOUND? submitting...
PROOF OF WORK RESULT: true (yay!!!)
PROOF OF WORK FOUND? submitting...
PROOF OF WORK RESULT: true (yay!!!)
PROOF OF WORK FOUND? submitting...
PROOF OF WORK RESULT: true (yay!!!)
PROOF OF WORK FOUND? submitting...
PROOF OF WORK RESULT: true (yay!!!)
HTTP request failed: The requested URL returned error: 502
json_rpc_call failed, retry after 30 seconds
HTTP request failed: The requested URL returned error: 502
json_rpc_call failed, retry after 30 seconds
PROOF OF WORK FOUND? submitting...
PROOF OF WORK RESULT: true (yay!!!)
PROOF OF WORK FOUND? submitting...
PROOF OF WORK RESULT: true (yay!!!)
PROOF OF WORK FOUND? submitting...
PROOF OF WORK RESULT: true (yay!!!)
PROOF OF WORK FOUND? submitting...
PROOF OF WORK RESULT: true (yay!!!)
PROOF OF WORK FOUND? submitting...
PROOF OF WORK RESULT: true (yay!!!)
PROOF OF WORK FOUND? submitting...
PROOF OF WORK RESULT: true (yay!!!)
HTTP request failed: The requested URL returned error: 502
json_rpc_call failed, retry after 30 seconds
PROOF OF WORK FOUND? submitting...
PROOF OF WORK RESULT: true (yay!!!)
PROOF OF WORK FOUND? submitting...
PROOF OF WORK RESULT: true (yay!!!)
PROOF OF WORK FOUND? submitting...
PROOF OF WORK RESULT: true (yay!!!)
PROOF OF WORK FOUND? submitting...
PROOF OF WORK RESULT: true (yay!!!)
|
|
|
|
|
It is supposed to exit immediately upon Ctrl-C.
Rai said "it exits immediately", which I interpreted to mean "exits as soon as it is run, without calculating any hashes." That would be a huge problem, indicating that cpuminer no longer did any useful work! Rai clarified in a later post.
Everything appears to be working correctly on Windows.
|
|
|
|
+1 good stuff Suggestions: |
|
|
|
Running on Windows 7 Ultimate with an Intel Core 2 Duo 2.4 ghz
It seems to exit immediately, but it could just be exiting properly too fast for me to notice. Is there a way to tell if it is exiting properly?
What arguments are you passing to minerd? Have you verified that version 0.3.3 works with the same command line? The purpose of a miner is to continue running into infinity, so it should only exit if downloading work via JSON-RPC is repeatedly failing. |
|
|
|
|
What is the difference between lost coins, and coins that people have been saving for a long time?
|
|
|
|
|
Version 0.5 is released. See top post for URLs. Changes:
- Exit program, when all threads have exited
- Improve JSON-RPC failure diagnostics and resilience
- Add --quiet option, to disable hashmeter output.
SHA1: 59a6b409c016468fb195619e46efe14db2f1aca8 cpuminer-installer-0.5.zip
MD5: 9d3fca8067ed4a3de9fb1df9d066c7be cpuminer-installer-0.5.zip
The new logic to wait for thread exit should work just fine under Windows. Let me know if version 0.5 behaves strangely under Windows, doing things like exiting immediately.
|
|
|
|
Thank you jgarzik. So, in theory, that means that the relation between PLN and BTC could be different than the relation between USD and BTC shown on mtgox? Of course this won't be off by much, because then people will go somewhere else, unless someone is selling coins for nothing? For some reason I was thinking that my exchange would have to monitor values on mtgox and follow it. Stupid me.
Option 1: In an open market exchange, an exchange assumes a neutral role, connecting (a) people selling PLN for BTC with (b) people selling BTC for PLN. The exchange rate is based on the most-recent currency trade between users. If there is a difference between BTC/PLN and BTC/USD rate, then users may make a profit on that difference through arbitrage. Option 2: In a for-profit currency exchange, you are seeking to (a) sell PLN, buy BTC or (b) buy PLN, sell BTC for customers. You set the exchange rate, based on your informed knowledge of BTC, USD and PLN exchange rates, and customers will buy--or not--based on your store's exchange rates. Remember, value of USD and PLN varies in the real world too! |
|
|
|
One thing I don't know how to approach is how to build up a graph that would show relation between BTC and PLN (Polish Zloty)? I don't mean how to draw it, but where to get the current value of PLN from? Would I have to connect to mtgox first and then check how PLN is to USD?
The value of PLN is based on each BTC/PLN trade that occurs on the BTC/PLN exchange. The traders who create orders on the BTN/PLN exchange are the ones who determine the current value -- which is, by definition, the value of the most recent BTN/PLN completed trade. This describes automated currency exchanges -- open markets -- such as mtgox. Other sites that perform manual currency exchanges simply calculate an exchange rate based on |
|
|
|
|
The English wiki seems to have some sort contributor reward system. Presumably we can do the same for the Chinese wiki, though I have no idea how to prevent spam pages...
|
|
|
|
Oops, my bad. I edited the project description. jgarzik, are you still in? If the FAQ task is complete, there's no point in a bounty for that. But I would pledge 100 BTC to see a Chinese (simplified) version of the wiki. |
|
|
|
|
Note that some of these stability fixes are only in cpuminer.git at the moment, not in a released tarball / Windows installer.
|
|
|
|
There are some currency exchange applications available but seem unsuported and out of date. Mostly for LETS type systems.
But this is not the problem, how is the RMB given to the purchaser? How can they use their RMB that they have bought with BTC? How can they get it? And how can someone who wishes to purchase BTC get their RMB to the exchanger?
This kind of system is entirely illegal here, even electronically there is no way to transfer RMB out of the country. From account to account (in China) you must use UnionPay, it is the only interbank transfer service in China. For online processing you must use ChinaPay.
BTC coming in is no difficult problem, but how to redeem your exchange, ok you know you have RMB, held for you in China, what then?
Yes, to be legal, this exchange would be limited to in-country, China-only RMB deposits and withdrawals. This is similar to https://btcex.com/ which only permits deposit/withdrawal of Rubles in Russia, too, if I understand correctly. Each exchange must comply with national money transfer laws. |
|
|
|
|
Show Posts
