|
If I were to rewrite the JSON-RPC interface from scratch, I would probably use strings to represent the full int64 bitcoin value, without any decimals.
But perfect is the enemy of good.
Our current interface works just fine, and all this is making a mountain out of a molehill. I do not see the value in changing what is currently in use.
|
|
|
|
Actually, JSON-RPC doesn't support integer nor floating-point. It supports "number", which is not necessarily either.
Irrelevant distinction. The definition of "number" requires support for decimal numbers. That said, many libraries are smart -- such as jansson -- and will evaluate a number directly into an integer. |
|
|
|
|
SSL is (a) a good additional to the bitcoin P2P protocol, even if anonymous, and (b) easy to integrate into the existing protocol.
As others have pointed out, SSL will not give you authentication, because you're still connecting to an untrusted party. However, it will give you obfuscation, which has value.
Modern protocols implement SSL by including a "start SSL" message in their plaintext, unencrypted protocol. That eliminates the need for multiple TCP ports as in the HTTP/HTTPS design. bitcoin can implement SSL obfuscation by adding a start-ssl message immediately after the version message. The version message will tell us whether or not the node supports SSL, making it easy to integrate SSL in a backwards-compatible manner.
Thus, bitcoin P2P nodes that wish SSL may request it, just like SMTP nodes that wish to use SSL for transiting email between untrusted nodes.
It is a step forward for the Internet, when most protocols use SSL by default, even if obfuscation is the only added value.
|
|
|
|
2. On first run Bitcoin should select a random high TCP port (>1024) and save it to the bitcoin.conf. (something like "listenerport=8972"). This port should contain the new SSL-only listener. Do we need to keep the old port 8333 listener running for compatibility for a while? The official client won't make outgoing connections to non-standard ports, so this would not be good for the network. This is a deficiency in the official client, and should be fixed. |
|
|
|
|
cpuminer version 0.6 released (see top of thread for URLs).
Changes:
- Fetch new work unit, if scanhash takes longer than 5 seconds (--scantime)
- BeeCee1's sha256 4way optimizations (faster!)
- lfm's byte swap optimization (faster! improves via, cryptopp)
- Fix non-working short options -q, -r
SHA1: d4c21a3fc1c3f433771101cf1e71186df3a94032 cpuminer-installer-0.6.zip
MD5: 1936f4f71574643825f8d8d31e456a3a cpuminer-installer-0.6.zip
|
|
|
|
Per their API documentation [1] amounts may be to an accuracy of 4 decimal places. Keep in mind that Pecunix has disabled its API for outgoing payments since 2008-ish. To automate this you'd have to do some screenscraping and resolve their (simple) Captcha. [1] http://info.pecunix.com/Pecunix_pri.htmDo you mean that they don't have an SCI ? PRI == SCI, at Pecunix. Thus, bitcoin central PGAU deposits can be automated, but bitcoin central PGAU withdrawals require you to manually login to their website and issue payments. |
|
|
|
please specify:
currently BC (bitcoin-central) supports only free trading
if there are matching buy/sell trade orders, they are mutualy satisfied, balances changed and the site operator has 0 % revenue
Q1: do you accept this behavior or how to you want to control transaction fees?
Q2: if fees yes, do you want a global fee applicable to all supported currencies?
Q3: do you want a fee per currency, default fee applicable if currency fee not selected or not known yet (p.ex. after currency added but the fee for transactions in that currency not specified yet)?
Q4: if fees yes, do you want to charge them in BTC or in the currency of transction?
Q5: currently BC only allows funded transactions. how would you update PecGAU balances of funded accounts?
(hint manually, pecunix api)
are you familiar with the fact that there is one wallet per currency and the balances are stored in a database?
is that in line with your imagination of pecunix support?
That's over-thinking the problem. Simply expressed, duplicate existing LRUSD support for Pecunix GAU, using Pecunix's API rather than LR's API. PGAU balance will appear beside LRUSD, and BTC/PGAU may be traded as BTC/LRUSD are traded now. |
|
|
|
|
I'll offer 500 BTC to the person or group that contributes working Pecunix GAU support to bitcoin-central open source project.
|
|
|
|
Distro's use cryptographically signed packages rather than checksummed ones.
Don't be so literal  "Checksum" is convenient shorthand. You see this with the "sum" prefix in binaries named "md5sum", "sha1sum", etc. |
|
|
|
|
One FAQ I get is "why not use Paypal?"
My answer is: Paypal is a layer on top of currencies. Paypal offers digital access and fraud protection on top of various currencies (USD, EUR, JPY, ...). In the distant future, Paypal would hopefully offer BTC as a supported currency, alongside USD and EUR.
|
|
|
|
Just to list potential sources of non-determinism that I know of when building on linux: - zip/gzip (timestamps)
- tar (timestamps)
- dependencies (libraries, headers)
- compilers
- things I am forgetting right now
We should not be building anything except bitcoin itself. Choose a distro with checksum'd packages, and you wipe out almost everything on your list. |
|
|
|
|
With modern packaging, checksumming is quite easy -- provided that prelink is disabled (prelink rewrites binaries). So gavin's proposal seems reasonable, and reproducible.
|
|
|
|
Encryption is pointless, because when an attacker can control enough bitcoin nodes, SSL won't help at all...
Encryption is not pointless, because it is unlikely an attacker can control enough bitcoin nodes today. Furthermore, it is nice to not be observed when I am submitting a new transaction to the network. Those in the coffee shop have no business knowing that I am submitting a new transaction, even if the TX is propagated in the clear throughout the network. |
|
|
|
"Starbucks launches largest mobile payment program in the US" http://www.techspot.com/news/42051-starbucks-launches-largest-mobile-payment-program-in-the-us.htmlTo pay with their phone, app users simply select "touch to pay" and hold up the barcode on the screen to the 2D scanner at the register.
and Starbucks is using its own custom-built technology, choosing barcode scanning over near field communication technology (NFC) because the latter has limited availability. The company may go NFC once there are enough mobile customers using it, but in the meantime it wanted to roll out mobile payments.
|
|
|
|
I found the configure script didn't correctly recognize my cpu (an I5) on Ubuntu 10.10. Since it didn't ID it, I didn't get SSE2 4way support. I added -msse2 -march=core2 to the CFLAGS and it worked (I added it in the Makefile, but adding it in the configure script should work). If you don't get SSE2 support you can try this.
I also found changing the -O2 to -O4 gave me a bit more than a 2% speed increase. I'll take every khash I can get.
Yeah, the configure script is not intended to "recognize your cpu." If you are doing your own builds, you are expected to be able to supply the best compiler flags for your CPU through the CFLAGS environment variable. This is the standard, recognized method for passing compiler flags to 95% of all configure scripts: CFLAGS="-O3 -march=native" ./configure
-march=native tells recent gcc versions to build programs tuned specificaly for the build machine's CPU (and may not work on other CPUs). By default, the compiler tries to generate code that is best suited to a wide range of CPUs. |
|
|
|
both have a different rcport specified in the config (8332 and 8333)
8333 is the hardcoded P2P port. |
|
|
|
Another quick question:
The cafe I'm talking to is very interested, but wants to know what the hardware will cost. The same person who runs the cafe also runs a food buyers club where orders are processed online. They currently use paypal or check to process payments. Would this retail payment system jive with an online system? Could people ordering bulk food online pay with their smartphone?
Right now: yes, if you are highly technical and can obtain the full-bitcoin-for-Android build. In the future: yes, people are working hard on an easy bitcoin smartphone app |
|
|
|
The JSON output is broken. There is no comma following the "eur" data closing brace. There may be other errors, but that's the one I'm seeing. Most languages have some sort of JSON validation code that you could use, just as a self-check against this sort of problem. I would run your XML through an XML validation as well. Yea... I've been generating json by hand which was probably a bad idea, guess I should fall back to the nice Hash#to_json method Also I'd need a DTD to validate my XML against, I guess the whole API is going to need some attention. If you could fix this one JSON issue, I can get bitcoin-central listed on bitcoinwatch. That bitcoin-central JSON breakage is my only blocker. |
|
|
|
I got a call from someone recently with a similar problem. He was using Windows 7 (the 64 bit version). I told him to use http://mybitcoin.com instead. IMHO, most "average users" should be using a website, rather than bitcoin software. bitcoin software is mainly for highly technical people, or people very interested in privacy (ie. they might run bitcoin over Tor). |
|
|
|
|
Show Posts
