[GNC] Bitcoin Lightning payments

HSC contact at highseas.capital
Sat Jun 18 17:18:36 EDT 2022


> 

> Message: 7
> Date: Sat, 18 Jun 2022 09:43:13 -0400
> From: Michael or Penny Novack stepbystepfarm at comcast.net
> 

> To: gnucash-user at gnucash.org
> Subject: Re: [GNC] Bitcoin Lightning payments
> Message-ID: 55b50d3d-18ce-8176-01d1-39616d6b129f at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.gnucash.org/pipermail/gnucash-user/attachments/20220618/8c1c464e/attachment.sig>


More information about the gnucash-user mailing list