If we really must have hexadecimal notation, can't we use a different exponent marker for hexadecimal values? e.g. 500e8 for decimals, and 0xf00x8 for hexadecimal. Treating 'e' like this only for decimal values would not break backward compatibility. No objection from me. |
|
|
|
Working on some slight modifications to make it pull-able and will send in a pull request when I'm done. (mostly removing tonal/hex stuff which jgarzik specifically objected to and adding support for Windows and OSX) This is exactly what I object to. We've already got ParseMoney in util.cpp, this patch adds parseNumber/uriParseAmount. Having more than one way to convert strings into bitcoin amounts is not a good idea, in my humble opinion. I agree, except that ParseMoney does not comply with the spec, and is not suitable to URIs. Also, instead of having a separate executable it would be more 'wxbitcoin-like' to have one executable that acts as either client or server depending on what command-line arguments are given. The problem with two executables is you'll have clueless users double-clicking on bitcoinuri.exe and then wondering why it doesn't do anything. The problem with a single executable, is that the OS will load and link everything for every URI click. |
|
|
|
Final and MIT licensed version: http://luke.dashjr.org/programs/bitcoin/w/bitcoind/luke-jr.git/commitdiff/d32bebafd41fac885055274ebf6142b960d1345eI put a lot of work into doing this perfectly, at way below cost from what I would usually charge for programming, so I would like to request it only be merged as-is, with any pre-merge changes made by me. Specifically, I have concerns about jgarzik and tcatm trying to break the entire URI specification 3 months after it's been implemented in every* client except their own. Obviously, my request still leaves them room to do so post-merge, but at least this way people who have problems can be pointed to a specific breaking revision to revert to fix it. And to clear up any FUD in advance: the URI spec and implementation herein do not in any way constitute "Tonal support". The changes to the spec irrationally demanded by the trolls involves making it absurdly more difficult for Tonal users (at no gain to Decimal users), and also makes it more difficult/annoying for Decimal users in the future when everyone is using milli- or micro-bitcoins. At the same time, their change is effectively attempting to repeat one of the known (and agreed by a general consensus, in numerous other forum threads) design flaws in the JSON-RPC protocol. |
|
|
|
|
Someone gaming faucet again -.-
|
|
|
|
Except that JSON-RPC is utterly unusable to implement any kind of real client. Can you be more specific? Sounds like vague handwaving. Read the wiki page that talks about requirements. The biggest problem is that JSON-RPC requires polling. |
|
|
|
I mentioned it on IRC that I don't see a need for bitcoind to have any process forking behavior in it... Disagree. What if startup fails? Forking after startup has succeeded allows one to not only know if there was a problem, but also block until the server is running (and can therefore know a connect will immediately succeed). |
|
|
|
|
Sounds like a good idea, though I think for a real CLI client, output should be formatted for human consumption, not merely pretty-printed JSON.
Why not split bitcoin-cli out from bitcoind? It's not like they share much code (besides the JSON library, which can be dynamically linked as it should be).
|
|
|
|
So after all that .... any update on opinions of how bitcoin should be commonly measured? TBC! No, seriously, that's why we have the different units. If you're making micro-payments, cBTC or mBTC might make sense for now. If you're doing a huge payment, consider kBTC. If you use Tonal, you'll probably want to use ᵇTBC for most payments. In a few years, the value changes will probably adjust everything to mBTC/TBC (for normal sizes) and μBTC/TBCᵐ for micro-payments. |
|
|
|
In general, though, I've found it better to first define what you want to do, then define the protocol to accomplish what you want to do. So, what do you want to do with the wallet? Obviously, first and foremost is to accept and spend coins.
The idea is that you can store the wallet anywhere and use it through a lightweight terminal, without connecting to the network. For example you could choose to store your coins at mybitcoin.com or your own server. Then you could use them with a Firefox extension or an Android UI. I think it would be easiest to go with the current JSON-RPC stuff and automatically enable it, or at least add it to the options menu. Well planned is not done. Except that JSON-RPC is utterly unusable to implement any kind of real client. Check out the ugly hacks in Spesmilo and js-remote that only workaround part of the problem. |
|
|
|
|
I see the potential use, but it would require Bitcoin clients to support HTTP (arguably not a problem, as JSON-RPC and the current Wallet protocol draft also require it) and more problematic: HTML parsing...
Also, your argument can be used in reverse: nobody could use your suggestion today, but many Bitcoin clients already support normal links to bitcoin: URIs. Sure, I could add a <link/> to my website, but it would have no practical use unless someone installed a (currently non-existent) client for it. I'm sure a simple ECMAScript to rewrite bitcoin: links when support is missing wouldn't be too difficult either...
|
|
|
|
There are no special words for 10 metres or 0.1mm, for example. 10 metres = decametre Do people tend to work in feet, or use mixtures? I see things like 1' 2" which suggests units get mixed, but I don't know if that's just when written or if people think in mixtures as well). Honestly, I don't measure enough to work in any unit really. When I measure stuff, I find something I can easily work with (eg, pillow-lengths to measure bedrooms) on the spot. I do plan to order some nice Tonal rules, though...  My problem with AS is that the "number" keeps changing: 12 inches in a foot, 3 feet in a yard, and I can never remember how many yards (or feet) in a mile. I can see potential advantages in using 12 instead of 10 - if there was a system that had 12 inches to a foot, 12 feet to a "bigyard", and 12 bigyards to a "twelvemile" then I could see some value in that. But 10, or - better - 1000, seems perfectly usable to me. There is such a system. It's called TGM. |
|
|
|
Are you just being amusing, or do you really see any benefits in those crazy backwardds units? Metric/SI is the backward units. Decimal really does suck. Seriously, just look at history: people naturally see the benefit of, and move toward, bases 6*2 and 8*2, DESPITE writing them in base 5*2. People only go back to base 5*2 units when forced. It's obvious which is superior. Now the question is, why do people still use base 5*2 for writing? |
|
|
|
For now, use this: make -f makefile.unix USE_UPNP= Yes, that's a null value, not a 0. |
|
|
|
|
What timezone and locale is your bitcoind running in?
|
|
|
|
I don't like the idea of 'preserving the familiar'. If we did that, America would still be using feet and inches... oh, wait. Feet and inches are far better than the common alternative of metres. The latter is based on decimal, one of the worst possible radices, and has only ever been adopted by force. America deserves credit for not forcing people to use an inferior system. |
|
|
|
|
Perhaps useful for in-person address communication
|
|
|
|
The sooner people exploit an insecure system, the sooner the people that made it will fix it. You have my gratitude, dishwara. Nothing motivates human action like losing money. Anonymity is inherently insecure in this regard. Are you saying we need to get rid of that? |
|
|
|
|
Show Posts
