Good googley moogley thats complex! Nice work. It's not done, and draft 0 is looking too complex to become final. That appears to be a communication protocol.... I'm just worried about how the keys are stored which should be addressed well below that level. How the keys are stored is strictly up to the Wallet software. The protocol allows you to easily export/import/access keys from any software using it. If you had your wallet protocol up and running on your machine I should be able to walk up to it, plug in my usb stick with my keys and let err rip while only allowing your app to access what I want. What you've outlined has the application layer determining what keys can be accessed. What if I don't want to give your application access to all my keys? Or I trust your application with my business accounts but not the personal accounts? What if there are competing wallet protocols for different specialized purposes? Your keys should still be able to transfer seamlessly between them. The point of protocol standards is compatibility. A good standard should need no competition for a long time. Specialized purposes can use extensions. A Bitcoin USB key would implement the protocol, allowing applications to only access keys you unlock with username/password-- or even make spends without access to the keys. |
|
|
|
|
Poll reset to allow revoting now that clarifications have been made.
|
|
|
|
I really don't see why you guys care so much about removing flexibility from the URI scheme. If you work on enough software, you come to realize that features with near-zero userbase just waste precious developer time, increase complexity costs far beyond any payback received, and wind up needlessly complicated users' lives in unexpected ways. 1. The reason there is near-zero userbase, is directly because there is near-zero support of the features. 2. I have already "wasted" my precious developer time implementing it. 3. It in no way complicates any users' lives, although removal would complicate tonal users' lives (or rather, they probably just are less likely to use Bitcoin). |
|
|
|
More importantly, both the oldest and newest Win32 nightlies on the site crash when stopped.
I can't reproduce, could you provide more information (ie Windows version, etc) Windows 7, vanilla fresh install. 1. Run start /B bitcoind -rpcpassword=1 (wait for it to finish startup) 2. Run bitcoind -rpcpassword=1 stop 3. Windows says it crashed (and db error visible) |
|
|
|
It's better to keep a standard output and then have any specialized interfaces convert as needed. This isn't about output, it's about input from ANY possible third party. |
|
|
|
things to avoid
----------------------------------------------------
Breaking changes, like Luke JR's RPC versioning changes. More trolling, I see. For anyone interested, my RPCv1 changes do NOT break anything, and are completely backward compatible. Weren't those the ones that didn't actually do anything? No. More importantly, both the oldest and newest Win32 nightlies on the site crash when stopped. |
|
|
|
In fact, I just went through every possible encoding scheme for this page - none of them show actual characters in place of the squares.
More likely a font problem than encoding. |
|
|
|
|
It is biased. For one, NOBODY HAS ANY TONAL SUPPORT IN ANYTHING. For two, you don't clarify that supporting hexadecimal has NO NEGATIVE EFFECTS, and that people can still use decimal
|
|
|
|
things to avoid
----------------------------------------------------
Breaking changes, like Luke JR's RPC versioning changes. More trolling, I see. For anyone interested, my RPCv1 changes do NOT break anything, and are completely backward compatible. |
|
|
|
URIs are not meant to be read by humans, so people being "familiar" with all possibilities is irrelevant. Why do you even care what is supported, then? Humans shouldn't need to read them, but humans often do write them. 2. You assume a glim future where people still use not only decimal, but BTC. This is not even rationally possible: people will either use mBTC, TBC, or Bitcoin will fail outright. Everyone will at least understand decimal for the next 100 years. Everyone will understand what an original BTC represents for as long as Bitcoin exists. Are you sure? Most of the world is in major population reduction mode, while at least I personally hope to have many more children (4 so far). Only takes a few generations, and I'm just one person. You imply supporting hexadecimal is difficult. It's a waste of time. It's not your time. Every client except apparently js-remote has a full implementation already. Removing that implementation would be the real waste of time. If tcatm wants to complain about the time to implement it for js-remote, I'd be glad to do it for him. |
|
|
|
|
This depends on some kind of standard API to interface with markets, and a centralized list of markets providing the service. Clients can then allow the user to search by accepted payment method, warn them that it's through a third party, and display a list of exchanges sorted by price...
|
|
|
|
You're using emotionally-charged words in the poll. Few people will vote for "forcing" anyone to do anything. Maybe the options should be changed to: - Accept only normal decimal BTC amounts that everyone is guaranteed to be familiar with now and forever
- Force developers of Bitcoin URI software to support hexadecimal values on the slim chance that one of the few people who deal in hexadecimal wants to edit a Bitcoin URI manually
- Accept hexadecimal and yet another rarely-used number base, forcing developers to do even more work.
1. URIs are not meant to be read by humans, so people being "familiar" with all possibilities is irrelevant. 2. You assume a glim future where people still use not only decimal, but BTC. This is not even rationally possible: people will either use mBTC, TBC, or Bitcoin will fail outright. 3. You imply supporting hexadecimal is difficult. 4. Dozenal has a rather large userbase too. |
|
|
|
|
Objectively, the decimal-only option isn't rational, so the meaning of this poll remains: to show how bigoted the people on this forum are.
|
|
|
|
This poll is biased and therefore meaningless.  Is not |
|
|
|
Should Bitcoin: URIs be allowed to contain only decimal bitcoins (BTC), or tolerate the human's choice of BTC or TBC (converted first to hexadecimal)? Please note that even if hexadecimal is supported, nobody is required to use it. It remains the user's choice which number system they use. Even if you open a URI encoded in hexadecimal, you will see the Decimal/BTC equivalent in your client (unless you configure it for TBC). In other words, a vote for decimal-only is a vote to force humans who want to use tonal to switch to decimal.If you want to request/bill for 10.25 BTC, you (or your shopping cart) would write: - Decimal only: bitcoin:youraddress?amount=10.25
- Decimal or hexadecimal: bitcoin:youraddress?amount=10.25
- Decimal or duodeci or hexadeci: bitcoin:youraddress?amount=10.25
If you want to request/bill for 1.5 mBTC (milli-BTC), you (or your shopping cart) would write: - Decimal only: bitcoin:youraddress?amount=0.0015
- Decimal or hexadecimal: bitcoin:youraddress?amount=0.0015
- Decimal or duodeci or hexadeci: bitcoin:youraddress?amount=0.0015
If you want to request/bill for 10.2 TBC (TonalBitcoin), you (or your shopping cart) would write: - Decimal only: bitcoin:youraddress?amount=0.01056768
- Decimal or hexadecimal: bitcoin:youraddress?amount=x10.2
- Decimal or duodeci or hexadeci: bitcoin:youraddress?amount=x10.2
If you want to request/bill for 1 ᵐTBC (mill-TonalBitcoin), you (or your shopping cart) would write: - Decimal only: bitcoin:youraddress?amount=2.68435456
- Decimal or hexadecimal: bitcoin:youraddress?amount=x1000
- Decimal or duodeci or hexadeci: bitcoin:youraddress?amount=x1000
|
|
|
|
Assuming they use high-level amounts, should Bitcoin: URIs support only present-day common-use BTC quantities, or should people be able to adapt it over time to different sizes? Should Bitcoin: URIs use low-level or high-level units? If you want to request/bill for 10.25 BTC, you (or your shopping cart) would write: - Only support present-day standard units: bitcoin:youraddress?amount=10.25
- Optionally support specifying exponent: bitcoin:youraddress?amount=10.25 or bitcoin:youraddress?amount=10.25e8
- Require specifying exponent: bitcoin:youraddress?amount=10.25e8
If you want to request/bill for 1.5 mBTC (milli-BTC), you (or your shopping cart) would write: - Only support present-day standard units: bitcoin:youraddress?amount=0.0015
- Optionally support specifying exponent: bitcoin:youraddress?amount=0.0015 or bitcoin:youraddress?amount=1.5e5
- Require specifying exponent: bitcoin:youraddress?amount=1.5e5
If you want to request/bill for 10.2 TBC (TonalBitcoin), you (or your shopping cart) would write: - With hex support:
- Only support present-day standard units: bitcoin:youraddress?amount=x10.2
- Optionally support specifying exponent: bitcoin:youraddress?amount=x10.2 or bitcoin:youraddress?amount=x10.2x4
- Require specifying exponent: bitcoin:youraddress?amount=x10.2x4
- Without hex support:
- Only support present-day standard units: bitcoin:youraddress?amount=0.01056768
- Optionally support specifying exponent: bitcoin:youraddress?amount=0.01056768 or bitcoin:youraddress?amount=1056768e0
- Require specifying exponent: bitcoin:youraddress?amount=1056768e0
If you want to request/bill for 1 ᵐTBC (mill-TonalBitcoin), you (or your shopping cart) would write: - With hex support:
- Only support present-day standard units: bitcoin:youraddress?amount=x1000
- Optionally support specifying exponent: bitcoin:youraddress?amount=x1000 or bitcoin:youraddress?amount=x1x7
- Require specifying exponent: bitcoin:youraddress?amount=x1x7
- Without hex support:
- Only support present-day standard units: bitcoin:youraddress?amount=2.68435456
- Optionally support specifying exponent: bitcoin:youraddress?amount=2.68435456 or bitcoin:youraddress?amount=268435456e0
- Require specifying exponent: bitcoin:youraddress?amount=268435456e0
|
|
|
|
Should Bitcoin: URIs use low-level or high-level units? If you want to request/bill for 1 BTC, you (or your shopping cart) would write: - Low-level: bitcoin:youraddress?amount=100000000
- High-level: bitcoin:youraddress?amount=1
If you want to request/bill for 1 mBTC (milli-BTC), you (or your shopping cart) would write: - Low-level: bitcoin:youraddress?amount=100000
- High-level: bitcoin:youraddress?amount=0.001
If you want to request/bill for 1 TBC (TonalBitcoin), you (or your shopping cart) would write: - Low-level: bitcoin:youraddress?amount=65536
- High-level (without hexadecimal support): bitcoin:youraddress?amount=0.00065536
- High-level (with hexadecimal support): bitcoin:youraddress?amount=x1
If you want to request/bill for 1 ᵐTBC (mill-TonalBitcoin), you (or your shopping cart) would write: - Low-level: bitcoin:youraddress?amount=268435456
- High-level (without hexadecimal support): bitcoin:youraddress?amount=2.68435456
- High-level (with hexadecimal support): bitcoin:youraddress?amount=x1000
|
|
|
|
|
This poll is biased and therefore meaningless. New polls created that are neutral.
|
|
|
|
Which is why 'e' would work for decimal, as Luke said.
But now that I think about it, 'e' isn't in the tonal alphabet, right? Correct, but the URI scheme doesn't support tonal. |
|
|
|
|
Show Posts
