📅 Original date posted:2012-01-31
📝 Original message:On Tuesday, January 31, 2012 9:27:26 AM Amir Taaki wrote:
> BIP 20 really has no support among implementations such as Bitcoin-Qt,
> Electrum, MultiBit or Bitcoin-JS.
It does among implementations such as Spesmilo and WalletBuddy, and has for
some time. More importantly, it achieved consensus and Final status before any
objections were made. Final only changes to Superceded. What's the point of a
formal BIP process if that process won't be followed?
> Also BIP 20 is problematic because it is incompatible with about every
> standard on the web. All the HTML, URI and everything uses decimal numbers
> alone. I see no reason for breaking with tradition.
That's not incompatibility, and not true. The standards use hexadecimal
numbers, and I can't even think of a single case off-hand where decimal is
used.
That being said, I'd be fine with a spec that used strtol-compatible satoshis
for amount. This is both simple and forward-compatible.
On Tuesday, January 31, 2012 9:53:57 AM Gary Rowe wrote:
> Regarding the decimal vs satoshi notation I see a few problems with
> satoshi:
>
> * readability - humans reading the URI would expect it to accurately
> reflect what is being displayed (subject to internationalisation issues)
> For example, amount=1.234 is more human readable than amount=123400000
> (ish)
This is true only for BTC users. While that might be a sensible unit today, it
almost certainly won't be in the future. amount=0.00001 is much worse than
amount=1000 or amount=1x3
> * backwards compatibility - existing software already uses the decimal
> notation
Existing software uses Satoshis internally, and it's generally regarded as a
design flaw that it uses BTC numbers in the JSON-RPC protocol.
> * forwards compatibility - Bitcoin needs to move beyond the satoshi to 20
> dps for some reason, this remains OK within the existing schema, but forces
> decimals into the satoshi scheme
This strikes me as more of "let's test the code earlier rather than later"
than forwards compatibility. The problem is that it's pretty much unanimous
that floating-point should never be used, and without that both
representations will be rounding when there are smaller units available.
Luke-Jr [ARCHIVE] /
npub1dt…u7wrs
2023-06-07 03:02:03
in reply to nevent1q…cjam
Author Public Key
npub1dtr22xd42nv07un2xq0rmtkqkjylgsmexau0anxxafa9xmmn2ncshu7wrsPublished at
2023-06-07 03:02:03Event JSON
{
"id": "595049ff5acf610f536d20f788174d8b9d2450d126c98bc55ecafb93639eb72b",
"pubkey": "6ac6a519b554d8ff726a301e3daec0b489f443793778feccc6ea7a536f7354f1",
"created_at": 1686106923,
"kind": 1,
"tags": [
[
"e",
"c2770ee47ac360316c351f988b594e57bfe1b484641917608b0707840470fbc3",
"",
"root"
],
[
"e",
"426b86b19d139ec3e0a5bfac1bb762fb36df4db2a80bc8d80805bcd38a0238fc",
"",
"reply"
],
[
"p",
"cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba"
]
],
"content": "📅 Original date posted:2012-01-31\n📝 Original message:On Tuesday, January 31, 2012 9:27:26 AM Amir Taaki wrote:\n\u003e BIP 20 really has no support among implementations such as Bitcoin-Qt,\n\u003e Electrum, MultiBit or Bitcoin-JS.\n\nIt does among implementations such as Spesmilo and WalletBuddy, and has for \nsome time. More importantly, it achieved consensus and Final status before any \nobjections were made. Final only changes to Superceded. What's the point of a \nformal BIP process if that process won't be followed?\n\n\u003e Also BIP 20 is problematic because it is incompatible with about every\n\u003e standard on the web. All the HTML, URI and everything uses decimal numbers\n\u003e alone. I see no reason for breaking with tradition.\n\nThat's not incompatibility, and not true. The standards use hexadecimal \nnumbers, and I can't even think of a single case off-hand where decimal is \nused.\n\nThat being said, I'd be fine with a spec that used strtol-compatible satoshis \nfor amount. This is both simple and forward-compatible.\n\nOn Tuesday, January 31, 2012 9:53:57 AM Gary Rowe wrote:\n\u003e Regarding the decimal vs satoshi notation I see a few problems with\n\u003e satoshi:\n\u003e \n\u003e * readability - humans reading the URI would expect it to accurately\n\u003e reflect what is being displayed (subject to internationalisation issues)\n\u003e For example, amount=1.234 is more human readable than amount=123400000\n\u003e (ish)\n\nThis is true only for BTC users. While that might be a sensible unit today, it \nalmost certainly won't be in the future. amount=0.00001 is much worse than \namount=1000 or amount=1x3\n\n\u003e * backwards compatibility - existing software already uses the decimal\n\u003e notation\n\nExisting software uses Satoshis internally, and it's generally regarded as a \ndesign flaw that it uses BTC numbers in the JSON-RPC protocol.\n\n\u003e * forwards compatibility - Bitcoin needs to move beyond the satoshi to 20\n\u003e dps for some reason, this remains OK within the existing schema, but forces\n\u003e decimals into the satoshi scheme\n\nThis strikes me as more of \"let's test the code earlier rather than later\" \nthan forwards compatibility. The problem is that it's pretty much unanimous \nthat floating-point should never be used, and without that both \nrepresentations will be rounding when there are smaller units available.",
"sig": "0febecef7720e1a77b76d59046ea857d783ab924c4ac028a19ae39ffd27e03ab25f300fd05e9fc6820d00318796910ecbb76f65def64ced8fe19009d9cb721a7"
}