Bitcoin Forum
December 09, 2016, 05:51:46 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2]  All
  Print  
Author Topic: [RFC] Sub-cent-precision  (Read 5424 times)
davout
Legendary
*
Offline Offline

Activity: 1358


1davout


View Profile WWW
February 01, 2011, 10:57:39 AM
 #21

I'm not sure I get people's points right, my opinion, summed up is :
 - GUI and JSON should allow every operation with full precision,
 - It's the responsibility of the miners/clients to decide which transactions they want to include/relay
 - No transaction fee should be auto-set, but not relaying free subcent transactions seems like a reasonable default



1481305906
Hero Member
*
Offline Offline

Posts: 1481305906

View Profile Personal Message (Offline)

Ignore
1481305906
Reply with quote  #2

1481305906
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Pieter Wuille
Legendary
*
qt
Offline Offline

Activity: 1036


View Profile WWW
February 01, 2011, 12:56:09 PM
 #22

My original post - though split off from its original thread by gavin - was mainly about the internal representation used by JSON-RPC, and it seems that's also what most discussion here was about. This is a detail, and although my personal opinion is that integer units are preferable, it may or may not be worth sacrificing backward compatibility for.

Concerning sub-cent precision itself, i think gavin's suggestion is very good. The JSON-RPC interface should support all transactions and accounting at full precision, the client should actively avoid creating fee-requiring transactions, and creation of fee-requiring transactions shouldn't occur without the user's knowledge. I would suggest adding an optional maxtxfee argument (overriding the default) to the RPC calls which cause transactions to be sent though - i don't like a global setting shared by possibly more than one JSON-RPC client.

aka sipa, core dev team

Tips and donations: 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa
davout
Legendary
*
Offline Offline

Activity: 1358


1davout


View Profile WWW
February 01, 2011, 01:03:38 PM
 #23

Concerning sub-cent precision itself, i think gavin's suggestion is very good. The JSON-RPC interface should support all transactions and accounting at full precision, the client should actively avoid creating fee-requiring transactions, and creation of fee-requiring transactions shouldn't occur without the user's knowledge. I would suggest adding an optional maxtxfee argument (overriding the default) to the RPC calls which cause transactions to be sent though - i don't like a global setting shared by possibly more than one JSON-RPC client.

There is no such thing as a fee-requiring-tx, the default miner won't mine for some transactions, but the warning message should not imply that it is the protocol that prevents very small free transactions but merely the default implementation of the miner.

grondilu
Legendary
*
Offline Offline

Activity: 1134


View Profile
February 01, 2011, 01:55:03 PM
 #24

Did you actually read the wiki page that you're describing as "cool"? This "Tonal Bitcoin" stuff is just stupid. "Bong-BitCoin" indeed!

Well, this is Nystrom hexadecimal representation (http://en.wikipedia.org/wiki/John_W._Nystrom#Tonal_System_.28Hexadecimal.29), isn't it?

It doesn't seem stupid to me.  Anyway, it's just a complement to the standard 10^3-based prefix system.

However, it's a bit unfortunate that the smallest amount is not exactly a nanobitcoin, but rather 10 nanobitcoins.  It would have been simpler.
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
February 01, 2011, 02:05:51 PM
 #25

Well, this is Nystrom hexadecimal representation (http://en.wikipedia.org/wiki/John_W._Nystrom#Tonal_System_.28Hexadecimal.29), isn't it?

It doesn't seem stupid to me.

The Nystrom representation itself isn't stupid, but using it for Bitcoin is. It brings absolutely nothing worthwhile to Bitcoin.

One bitcoin is 100000000 units of bitdust, and the maximum number of bitcoins is 21000000, both of which are convenient decimal numbers. What's the point of having one Bong-Bitcoin equal to 42.94967296 BTC?

If you do want to count bitcoins in hexadecimal, you should simply use the equivalent number in base 16. For example, 255 BTC = 0xFF BTC.
grondilu
Legendary
*
Offline Offline

Activity: 1134


View Profile
February 01, 2011, 02:10:28 PM
 #26

The Nystrom representation itself isn't stupid, but using it for Bitcoin is. It brings absolutely nothing worthwhile to Bitcoin.

It brings more names to bitcoin subdivisions.
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2100



View Profile
February 01, 2011, 02:31:06 PM
 #27

I'm splitting the Tonal talk to another thread. It doesn't belong here.

although my personal opinion is that integer units are preferable, it may or may not be worth sacrificing backward compatibility for.
Integer units don't break backward compatibility at all, if implemented using a RPC versioning mechanism (eg, bitcoin.<version>. prefix to methods, or--as MT suggested on IRC-- using a different URI path). This way, the old "RPC v0" can continue to function for as long as we care to maintain it, while new code can use RPC v1 with integer units. Given the fact that URIs are used, it might also be possible to simply use a query parameter (eg, "?precision=0", "?precision=1e8", "?precision=65536") to specify a division for all units explicitly (and default to "?precision=1e8" for backward compatibility for a while), while not forcing newer APIs to use base units.

Pieter Wuille
Legendary
*
qt
Offline Offline

Activity: 1036


View Profile WWW
February 01, 2011, 11:03:33 PM
 #28

There is no such thing as a fee-requiring-tx, the default miner won't mine for some transactions, but the warning message should not imply that it is the protocol that prevents very small free transactions but merely the default implementation of the miner.

Ok, agree. I think conventions for what and where fees are expected are a separate issue. But as long as no different set of rules is designed, and the client enforces those rules in the transactions it creates, no transactions that include a fee should be created beyond the user's (or JSON-RPC client's) control. Gavin's proposal does that nicely.

although my personal opinion is that integer units are preferable, it may or may not be worth sacrificing backward compatibility for.
Integer units don't break backward compatibility at all, if implemented using a RPC versioning mechanism (eg, bitcoin.<version>. prefix to methods, or--as MT suggested on IRC-- using a different URI path). This way, the old "RPC v0" can continue to function for as long as we care to maintain it, while new code can use RPC v1 with integer units.

Ok, agree as well. But again, maybe introducing a new version of the protocol may or may not be worth the effort.

Given the fact that URIs are used, it might also be possible to simply use a query parameter (eg, "?precision=0", "?precision=1e8", "?precision=65536") to specify a division for all units explicitly (and default to "?precision=1e8" for backward compatibility for a while), while not forcing newer APIs to use base units.

That comes close to my "Idea 1", and brings us back to the issue of whether it is the responsibility of the JSON server to provide encoding/formatting of numeric amounts for human readability (and humans with varying tastes).

aka sipa, core dev team

Tips and donations: 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2100



View Profile
February 05, 2011, 01:48:21 AM
 #29

Solution to buggy JSON libraries (with base unit amounts): append a ".0" to all amounts, even though fractions are not possible. This should force all libraries with these bugs to treat it as a floating-point type, which is capable of representing the entire range. Embedded systems where floating-point is a problem can still validly ignore the ".0" and use int64.

teknohog
Sr. Member
****
Offline Offline

Activity: 412


minor developer


View Profile WWW
February 05, 2011, 01:21:21 PM
 #30

However, it's a bit unfortunate that the smallest amount is not exactly a nanobitcoin, but rather 10 nanobitcoins.  It would have been simpler.

Chinese numerals are grouped in terms of 10^4, and the same system is used in Japan. I am not sure if this is the reason behind 10^-8 bitcoins, but at least it would appear simpler in those countries. 10^3 and 10^6 are only simpler for Westerners.

Then again, SI prefixes are by definition the international standard. If only they were actually used, instead of the billions and trillions whose meanings change by the country/continent.

Pages: « 1 [2]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!