[GNC] Bitcoin Lightning payments
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. Can’t find the Bitcoin stock vs currency discussion in the archive. Sorry if I overlooked it, but I read the workaround here: https://www.gnucash.org/docs/v4/C/gnucash-guide/currency_manual.html https://www.gnucash.org/docs/v4/C/gnucash-guide/currency_trading_accts.html. Seems awkward to treat it as a stock, and not sure that way is even precise, because Bitcoin tx fee is in BTC. Also, the tx fees is just being transferred to the miners; it’s not being sold for fiat by the payer. Main challenge at the moment though is Bitcoin Lightning Network payments. In attached example, the payment is sent to a payment processor via LN, converted to THB and sent to the vendor. If Bitcoin is treated as a stock with USD account unit, then GC first converts it into USD. Then have to account for BTC tx fee by rounding. On LN in particular, the fees are in milisats. (1-e11 BTC) In the example, it would be about 50 milisats = 5.0-e10 BTC. I could calculate what fraction of US cent that would be, but in the long-term would add a lot of accounting time for very small txs. Rounding will compound the errors. Is there a way to automate this calculation? Is my example even the best way to do that? Has anyone experience with some commercial accounting software that handles Bitcoin in an easier way as a currency that it is? Thank you for your attention. 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.
Re: [GNC] Bitcoin Lightning payments
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, 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 stepbystepf...@comcast.net > > To: gnucash-user@gnucash.org > Subject: Re: [GNC] Bitcoin Lightning payments > Message-ID: 967b4023-8d76-dc43-9fbe-f00854c99...@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 > > > > > 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.
Re: [GNC] Bitcoin Lightning payments
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 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-requ...@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 stepbystepf...@comcast.net > > > > To: gnucash-user@gnucash.org > > Subject: Re: [GNC] Bitcoin Lightning payments > > Message-ID: 967b4023-8d76-dc43-9fbe-f00854c99...@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 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.
Re: [GNC] Bitcoin Lightning payments
Yes, quite right! This workaround is for an account involving only BTC txs. Can still cross-currency by entering the rate manually, which should still be less trouble, busywork and error-prone than treating Bitcoin as a stock. Until Bitcoin is coded into GC as a proper currency and a possible unit of account, might be all we can do. HSC --- Original Message --- On Saturday, June 18th, 2022 at 07:10, Peter West wrote: > But you can’t then quotes for cross-currency values directly, because such > quotes will be expressed in terms of the primary unit - BTC, for example. > —Peter west...@pbw.id.au“But when you give to the needy, do not let your left > hand know what your right hand is doing, so that your giving may be in > secret.” > > > On 18 Jun 2022, at 4:36 pm, HSC wrote: > > > > 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 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-requ...@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 stepbystepf...@comcast.net > > > > > > > > > >
Re: [GNC] Bitcoin Lightning payments
> > 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.1 > (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.
[GNC] Multiple currencies in split tx
Hello, Found some related previous discussion in archive, but not yet the same. Is it possible to account in one GC split entry for a tx in which a payment processor simultaneously makes a payment to two different vendors in two different local currencies? We see it on the statement as one payment in source currency and two in destination currencies, without any details regarding conversion rates. Do we have to calculate all that manually, and enter in GC as two separate txs? 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.
Re: [GNC] Multiple currencies in split tx
> -- > > Message: 4 > Date: Thu, 30 Jun 2022 15:03:37 -0700 > From: list+gnuc...@jdlh.com > To: gnucash-user@gnucash.org > Subject: Re: [GNC] Multiple currencies in split tx > Message-ID: 2b04aeb5-7f10-cfa9-3960-261bbee4b...@jdlh.com > > Content-Type: text/plain; charset=UTF-8; format=flowed > > Hello, HSC: > > Welcome to GnuCash. > > On 2022-06-30 13:30, HSC wrote: > > > ...Is it possible to account in one GC split entry for a tx in which a > > payment processor simultaneously makes a payment to two different vendors > > in two different local currencies?... > > > In my experience, yes. I have made some transactions like this. > > > We see it on the statement as one payment in source currency and two in > > destination currencies, without any details regarding conversion rates. > > > > Do we have to calculate all that manually, and enter in GC as two separate > > txs? > > > My suggestions: > > 1. Read the "Multiple Currencies" section of the GnuCash Tutorial and > Concepts Guide > https://www.gnucash.org/docs/v4/C/gnucash-guide/chapter_currency.html > > > 2. Enable trading accounts (see 12.3 Automatically Recording Currency > Transactions?). I have always used trading accounts in GnuCash, so I > have no experience without trading accounts. > > 3. Know that each transaction has a default currency, but GnuCash does > not easily show you which currency that is. GnuCash sets the default > currency to be the currency of whichever account you were in when you > created the transaction.? If you have three currencies, $AA, $BB, and > $CC, and you want the transaction's default currency to be $CC, then go > to an account register which has $CC as its currency, and create the > transaction there. > > 4. You will have to establish an exchange rate between the currency of > each split of the transaction, and the default currency of the > transaction. For each split, if the account for that split uses the > transaction's default currency, GnuCash will accept the amount you type > in for that transaction. If the account for that split uses a different > currency, then GnuCash will display a "Transfer Funds" dialogue (See > 12.3.2.2. Transfer of Funds to a Foreign Currency). You will have to > determine an amount of the transaction's default currency which > corresponds to the split amount, in the split account's currency. > > 4.example. Suppose you have a transaction where you pay $AA 4.00, and > the payment processor pays out $BB 2.00 and $CC 1.00. Go to the source > account, which uses $AA. Enter a split for that account with the amount > 4.00. Add a split with an account which receives the $BB 2.00. Enter the > amount 2.00. A "Transfer Funds" dialogue appears. Enter the amount of > $AA which corresponds to $BB 2.00. (You need to determine this yourself, > if the payment processor does not document it for you.) Then add another > split with an account which receives the $CC 1.00. Enter the amount > 1.00. In a similar way, fill out the Transfer Funds dialogue to set up > an exchange rate between $AA and $CC. > > 5. GnuCash enforces a rule that, within every transaction, the sum of > all splits using a currency sum to zero. This includes splits with > trading accounts, which GnuCash creates based on what you entered in the > "Transfer Funds" dialogue. > > 5.example. In the transaction with a source payment of $AA 4.00, there > will be one split involving the source account, with a value of $AA > 4.00, and one or two splits involving the TRADING:$AA account, summing > to -$4.00. The sum for all the splits in $AA is zero. > > 6. Note that you can use GnuCash as a calculator, by entering > expressions in amount fields. See GnuCash Guide, 2.9.2.4. Using Entry > Shortcuts. I use this for splitting the calculating a fraction of the > total for individual splits. > > This is complicated to describe in words. I recommend doing some trial > and error to experiment, and learn it that way.? Save a copy of your > Book file as another name. Open that copy, and make some test > transactions. When you understand what you want to do, open your > original Book file, and enter the transaction. > > Does that help? > > Best regards, > ? ?Jim DeLaHunt > Thank you very much, Jim DeLaHunt, for such detailed response! It's most helpful! Previously tried unsuccessfully to figure it out with trading accounts, but if I understand correctly, the key is to start in the source account. So, we'll try that next. HSC signature.asc Description: OpenPGP digital signature __
Re: [GNC] Bitcoin Lightning payments
> -- > > Message: 2 > Date: Sun, 19 Jun 2022 15:02:33 +0100 > From: "Dr. David Kirkby" drkir...@kirkbymicrowave.co.uk > > To: Peter West p...@pbw.id.au > > Cc: gnucash-user@gnucash.org, stepbystepf...@comcast.net > Subject: Re: [GNC] Bitcoin Lightning payments > Message-ID: > CANX10hDqudKB9KuF=fmjds7+sumtn9f0e7wz-uwawuvv+4u...@mail.gmail.com > > Content-Type: text/plain; charset="UTF-8" > > On Sun, 19 Jun 2022 at 12:08, Peter West p...@pbw.id.au wrote: > > > If you wait for 4217, you?ll be waiting a long time. > > > > Or so it seems to me. > > > > ? > > Peter West > > p...@pbw.id.au > > > > According to the ISO website, they are looking at crypto, but it will not > be part of ISO 4217. That was written 2.5 years ago ??? > > https://www.iso.org/news/ref2466.html > > > > Dave > > > -- > Dr. David Kirkby, > Kirkby Microwave Ltd, > drkir...@kirkbymicrowave.co.uk > https://www.kirkbymicrowave.co.uk/ > Telephone 01621-680100./ +44 1621 680100 > > Registered in England & Wales, company number 08914892. > Registered office: > Stokes Hall Lodge, Burnham Rd, Althorne, Chelmsford, Essex, CM3 6DT, United > Kingdom > > > -- > > Message: 5 > Date: Sun, 19 Jun 2022 11:19:49 -0400 > From: Michael or Penny Novack stepbystepf...@comcast.net > > To: "Dr. David Kirkby" drkir...@kirkbymicrowave.co.uk > > Cc: gnucash-user@gnucash.org > Subject: Re: [GNC] Bitcoin Lightning payments > Message-ID: 5d7e263c-424a-28a6-3aaf-b12ec86f1...@comcast.net > > Content-Type: text/plain; charset=UTF-8; format=flowed > > > Obviously BTC > > > > In general I think standards are good - especially internationally > > agreed ones. But according to the ISO website > > > > https://www.iso.org/news/ref2466.html > > > > ISO 4217 is never going to cover cryptocurrencies.? ISO are apparently > > looking at crypto. > > No, I thought I explained why it COULDN'T be "BTC" > > That choice would violate an existing ISO standard. Unless Bhutan > adopted Bitcoin as a currency << hey, it might be easier/quicker to get > Bhutan to do that then getting the ISO to agree. >> The first thing the > > ISO would need to do is settle on what first two characters would be "no > state". There are lots cryptocurrencies so maybe want several character > pairs for "no state" > > Michael D Novack > This might speed Bitcoin through ISO, IF actually happens at BIS first: https://finbold.com/bank-for-international-settlements-to-allow-banks-to-keep-1-of-reserves-in-bitcoin/ ISO is hardly a real NGO; doubtful that they would ever approve a code that central bankers don't. Keeping a separate Bitcoin book, where 1$ is assumed to be 1 sat is workable so far, including for milisat accounting. How to link it to our fiat ledger is the next question. Should it be done by using GC as an sql file and setting up some database connector between the fiat and the Bitcoin files? 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.
Re: [GNC] Multiple currencies in split tx
> Date: Sat, 2 Jul 2022 02:38:11 -0500 > From: Adrien Monteleone adrien.montele...@lusfiber.net > > To: gnucash-u...@lists.gnucash.org > Subject: Re: [GNC] Multiple currencies in split tx > Message-ID: t9osl3$j5e$1...@ciao.gmane.io > > Content-Type: text/plain; charset=UTF-8; format=flowed > > Starting from the source account is good practice no matter the type of > transaction. > > Since funds in double-entry have to 'come from somewhere' and 'go to > somewhere', by always entering the transaction in the source account, > you are always choosing the destination(s). > > Life is much less confusing that way. (yes, yes, before anyone else > chimes in, I know there are sometimes complicated transactions with > multiple sources...) > > Regards, > Adrien Thanks, Adrien! Yes, what Jim DeLaHunt described worked, including the the separate tx fees, and came out exactly without imbalance, by entering the exchange rate equations into the dialogues manually. It's quite adequate! 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.
