> > Message: 7 > Date: Sat, 18 Jun 2022 09:43:13 -0400 > From: Michael or Penny Novack stepbystepf...@comcast.net >
> To: gnucash-user@gnucash.org > Subject: Re: [GNC] Bitcoin Lightning payments > Message-ID: 55b50d3d-18ce-8176-01d1-39616d6b1...@comcast.net > > There is a (potential) solution for that. Probably not workable for > ridiculously high number of decimal points* you described. But let's say > you needed something smaller than that range. > > It is called "scaling". You have probably seen examples of this if you > have looked at the annual report of organizations where the totals are > in the tens or hundreds of millions. Instead of being in whole dollars, > the report might be in units of a thousand dollars. It also works the > other way around. > > Thus if you needed to express quantities of the order of $0.00001 > (hundredths of a mil) but only had two decimal points available you > could scale to the mil instead of the dollar << in other words "1" would > stand for one mil, not one dollar >> If your problem is NOW the range of > > values being too large to fit in the fields, I'll refer you to the > reasoning below. > > Michael D Novack > > * PHYSICAL reality is constrained by relative number of decimal points > to a relatively small number, say at most, six or seven. I am talking > here about when "adding things". In other words, when talking about real > things, 1,000,000 and 1,000,001 are essentially equal. If you were > counting two heaps separately, how certain would you be that they were > actually unequal (or would an error in counting be more likely). We > don't use counting, addition, subtraction, etc. to make a decision like > that (though we could use "pairing"). In similar fashion, given two > pieces of glass, one on top of the other, could measure how much farther > apart in the middle than at the edges in wavelengths of light used to > make the observation, or by how much the curvature of the surface > departed from some conic section, but not in terms of the thickness of > the pieces of glass. > Thanks! I suppose we could have 2 Bitcoin books - one for txs over 1 BTC and one for txs under 1 BTC, expressed in sats. We are interested in accounting both sides of the Bitcoin range, because we are testing BTCPayServer, which is a FOSS Bitcoin e-commerce suite. It includes a Lightning node for accepting small, instant Bitcoin payments. When it's running, in addition to its e-commerce txs, it is also constantly routing peer to peer Lightning Network BTC payments and making small gains of a few sats or some hundreds of milisats for each such routing. Naturally, they can add up to significant amounts eventually. The server interface provides csv files to keep track of such income, which would be useful to track in GC as Lightning Network use increases. I suppose we should test how the GC Import Assistant fares with such inputs. HSC
signature.asc
Description: OpenPGP digital signature
_______________________________________________ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
