[GNC] Bitcoin Lightning payments

[HSC]

Unfortunately, the idea of pretending that 1$ = 1BTC doesn't work exactly as it should, because the Spend/Receive fields don't accept entries smaller than 0.01, even if smallest fraction for account is set to 1e-8.
Neither does setting the decimal places to 8 in Preferences > Numbers > Decimal places affect Spend/Receive fields. Even setting to 3 doesn't increase them beyond 2 decimal places.
GNC just blanks and ignores a number less than 0.01

That's tolerable, if we pretend that 1$ = 1 sat instead of 1 BTC, and round the the milisats of fees to nearest 10, as if they are US cents.
That should be close enough for the foreseeable.

HSC

------- Original Message -------
On Saturday, June 18th, 2022 at 04:05, HSC <contact at highseas.capital> wrote:


> 

> 

> 

> Thank you, Michael D Novack!
> That's a great solution until GNC development catches up to the crypto world: we will keep separate GNC file for each cryptoasset.
> 

> The remaining problem is that Bitcoin Lightning goes to 11 decimal places, and Ethereum I think goes to 16.
> Will round up to 1 sat for now, since it's still of insignificant value, but eventually that will also need some improvement.
> 

> Another thing is that moving from onchain Bitcoin to its Lightning layer channels and back is a Bitcoin transaction in itself, which involves an onchain fee to open the channel. (Subsequent instant txs in the LN channels are at most a few sats for substantial BTC amount, and small payments txs often cost less than 1 sat - a fraction of a US cent in value - as I mentioned.)
> So, I guess Lightning layer bitcoins will have to be represented by some other fiat of the obscure ones that start with L perhaps.
> 

> The other issue is exchanging BTC for USD stablecoins, such as USDC. Then would have to represent that USD with some other dollar, such as the CAD maybe?
> 

> Might get error-prone. Since even Bitcoin is over a decade old now, seems that it would be useful for GNC to allow "user-defined non-ISO" currencies, such as "XBT" used for Bitcoin on some exchanges.
> Seems unlikely that central banks will ever allow such currencies to become ISO.
> 

> 

> HSC
> 

> 

> ------- Original Message -------
> On Saturday, June 18th, 2022 at 02:56, gnucash-user-request at gnucash.org wrote:
> 

> 

> 

> > Today's Topics:
> > 

> > 1. Re: Bitcoin Lightning payments (Michael or Penny Novack)
> > 2. Re: Online crypto value quote (David T.)
> > 3. Re: Online crypto value quote (Geoff)
> > 

> > ----------------------------------------------------------------------
> > 

> > Message: 1
> > Date: Fri, 17 Jun 2022 22:45:25 -0400
> > From: Michael or Penny Novack stepbystepfarm at comcast.net
> > 

> > To: gnucash-user at gnucash.org
> > Subject: Re: [GNC] Bitcoin Lightning payments
> > Message-ID: 967b4023-8d76-dc43-9fbe-f00854c99980 at comcast.net
> > 

> > Content-Type: text/plain; charset=UTF-8; format=flowed
> > 

> > On 6/17/2022 9:21 PM, HSC wrote:
> > 

> > > Hello Everyone,
> > > 

> > > Haven?t used GC a couple years, and trying to recollect how it all works.
> > > 

> > > Current challenge is starting to work with payments and expenses that are exclusively in Bitcoin.
> > 

> > > Has anyone experience with some commercial accounting software that handles Bitcoin in an easier way as a currency that it is?
> > 

> > IF what you mean by "exclusively in bitcoin" is accounting JUST in
> > bitcoin, you would not have to treat it as stock/commodity evaluated in
> > some other currency. You could keep a set of books denominated in
> > bitcoin. The lack of a currency symbol is an illusion, as they are just
> > conventional symbols. Understand? In YOUR books "$" doesn't have to
> > stand for dollars, it could stand for "bitcoin".
> > 

> > Michael D Novack
-------------- 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/714dcde6/attachment.sig>