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] Bitcoin Lightning payments
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 ___ 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
On Sun, 19 Jun 2022 at 12:08, Peter West 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 ___ 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
On Sat, 18 Jun 2022 at 22:32, Michael or Penny Novack < stepbystepf...@comcast.net> wrote: > > ogram, just > b) NO, not a "lame excuse". Misunderstanding of what the ISO is/does. It sets STANDARDS. In other words, "for currency X use ABX" (or whatever). Dr. David, if there is no agreed standard for what the three letter currency code for "bitcoin" is, what should the developers use? Should they simply use ANY three characters not already in use for some currency that has an ISO currency code? There are > 17 thousand three character codes possible and only the order of a hundred or two in use. 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. Personally I feel while ISO is thinking about it, open source software should just get on an implement the obvious ones. The most obvious is bitcoin, and that would be BTC. The top 25 by market cap would probably satisfy almost all users. Another solution, which would obviously be more work, is for a use to create a text file with information about other currencies. BTW, years ago I had a Nigerian scammer try to scam me. I decided to get my own back, and got him up quote for various items. He thought he was going to get about $25,000 out of me, but he actually ended up with a huge phone bill phoning a very expensive number I had. He reckoned one FAX cost him $50. Anyway, I was very keen to pay in Jersey Royals, not USD, but he wanted USD. Had he Googled Jersey Royals, he would have realised that they were a variety of potato and not a currency. I had several months of fun winding him up > Michael D Novack 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 ___ 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
The existing structure of 4217 codes will not work for crypto. It uses the two-letter country code plus one letter for the currency. (Do any of these conflict with he three letter country codes? As it happens, yes: BTN, CHE, MKD) All these codes are mnemonic. (There may be a few for which that is stretching the point, but not for lack of wanting a mnemonic.) One letter will not do for crypto; there are too many, and they are proliferating. The upshot is that whatever happens to crypto designations through ISO, the structure will be different. One might select an otherwise unused first letter (X is the only contender) and provide two letters for designating the currency. That will severely restrict the mnemonic value of the code. There may well be competing schemes, but every exchange uses one – three or four letters from my observations – and that situation will soon enough resolve to a single set. Who knows what ISO will eventually come up with to accommodate crypto, except that it will not be the same structure? Does GnuCash make ANY use of the internal structure of 4217 codes? If so, there’s a development problem right there. If not, things are easier. As we speak, exchanges are providing cross-currency quotations for both ISO currencies and crypto. How do they do it? As long as the crypto designators (like BTC, BUSD, ETH, DOGE) are distinct from the currency designators, the indicated currency is unambiguous. If you wait for 4217, you’ll be waiting a long time. Or so it seems to me. — Peter West p...@pbw.id.au And taking the five loaves and the two fish, he looked up to heaven and said a blessing over them. Then he broke the loaves and gave them to the disciples to set before the crowd. > On 19 Jun 2022, at 7:32 am, Michael or Penny Novack > wrote: > … > I'll reply not a a developer but as somebody whose done LOTS of software > design in my day. > > a) If the developers did the job right, the ISO currency codes are not hard > coded but in "app data" read in when the program starts << that means they > can be changed without changing the code in any program, just data in a file. > > b) NO, not a "lame excuse". Misunderstanding of what the ISO is/does. It sets > STANDARDS. In other words, "for currency X use ABX" (or whatever). Dr. David, > if there is no agreed standard for what the three letter currency code for > "bitcoin" is, what should the developers use? Should they simply use ANY > three characters not already in use for some currency that has an ISO > currency code? There are > 17 thousand three character codes possible and > only the order of a hundred or two in use. Whatever they pick the odds are > worse then 10,000:1 it won't agree with the code chosen by any other team of > software developers OR with what eventually become the standardized currency > code for bitcoin if/when the ISO chooses one. > >Your beef should not be with the gnucash developers but with the ISO. You > bitcoin users need to lobby THEM to choose a code for bitcoin. Actually, > there are TWO standards you need them to choose. One one is the two character > prefix to be used when a currency that is not the currency of a nation state > (or union of states, like EU in EUR). Then the third character that means > "bitcoin". > >Actually, there ARE several codes (competing codes) in use for > Bitcoin. Any of those might end up as the eventual code except BTC (which > violates ISO 4217 because BT is the code for an existing nation state). When > I was suggesting that a two character code first, note that "CC" (for > "cryptocurrency" will not do as "CC" already assigned as a "country code". ___ 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
On 6/18/2022 2:00 PM, Adrien Monteleone wrote: I'm not arguing anything. I'm simply passing along what I've seen the devs talk about in prior threads. Of course, if they have time out of their day coding GnuCash to chime in, I'm sure they can enlighten you more on the issues they have to consider in the code, and why that decision was made. As far as I'm aware, they aren't specifically 'anti-crypto'. Perhaps if one of them (or an experienced user) has the time, they can put something in the FAQ on the subject. (it is a fairly frequent topic here on the list.) Of course, if you took the time to search the list archives, you'll find those discussions and explanations. I'll reply not a a developer but as somebody whose done LOTS of software design in my day. a) If the developers did the job right, the ISO currency codes are not hard coded but in "app data" read in when the program starts << that means they can be changed without changing the code in any program, just data in a file. b) NO, not a "lame excuse". Misunderstanding of what the ISO is/does. It sets STANDARDS. In other words, "for currency X use ABX" (or whatever). Dr. David, if there is no agreed standard for what the three letter currency code for "bitcoin" is, what should the developers use? Should they simply use ANY three characters not already in use for some currency that has an ISO currency code? There are > 17 thousand three character codes possible and only the order of a hundred or two in use. Whatever they pick the odds are worse then 10,000:1 it won't agree with the code chosen by any other team of software developers OR with what eventually become the standardized currency code for bitcoin if/when the ISO chooses one. Your beef should not be with the gnucash developers but with the ISO. You bitcoin users need to lobby THEM to choose a code for bitcoin. Actually, there are TWO standards you need them to choose. One one is the two character prefix to be used when a currency that is not the currency of a nation state (or union of states, like EU in EUR). Then the third character that means "bitcoin". Actually, there ARE several codes (competing codes) in use for Bitcoin. Any of those might end up as the eventual code except BTC (which violates ISO 4217 because BT is the code for an existing nation state). When I was suggesting that a two character code first, note that "CC" (for "cryptocurrency" will not do as "CC" already assigned as a "country code". Michael D Novack ___ 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
> > 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.
Re: [GNC] Bitcoin Lightning payments
I'm not arguing anything. I'm simply passing along what I've seen the devs talk about in prior threads. Of course, if they have time out of their day coding GnuCash to chime in, I'm sure they can enlighten you more on the issues they have to consider in the code, and why that decision was made. As far as I'm aware, they aren't specifically 'anti-crypto'. Perhaps if one of them (or an experienced user) has the time, they can put something in the FAQ on the subject. (it is a fairly frequent topic here on the list.) Of course, if you took the time to search the list archives, you'll find those discussions and explanations. Regards, Adrien On 6/18/22 10:38 AM, Dr. David Kirkby wrote: On Sat, 18 Jun 2022 at 16:12, Adrien Monteleone < adrien.montele...@lusfiber.net> wrote: I'm pretty sure the issue isn't GnuCash development. (based on previous threads) The issue is that BTC and other 'coins' don't have ISO currency codes. When/if they get one, GC will include them. Regards, Adrien That seems a *very* lame argument to me. Dave. ___ 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
On Sat, 18 Jun 2022 at 16:12, Adrien Monteleone < adrien.montele...@lusfiber.net> wrote: > I'm pretty sure the issue isn't GnuCash development. (based on previous > threads) The issue is that BTC and other 'coins' don't have ISO currency > codes. When/if they get one, GC will include them. > > Regards, > Adrien That seems a *very* lame argument to me. 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 ___ 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
I'm pretty sure the issue isn't GnuCash development. (based on previous threads) The issue is that BTC and other 'coins' don't have ISO currency codes. When/if they get one, GC will include them. Regards, Adrien On 6/17/22 11:05 PM, 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. ___ 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
On 6/18/2022 12:05 AM, 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. 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. PS --- Not the place to discuss what "money" is, but it isn't, even in the case of "fiat currencies" something that is determined by fiat. That's why governments, etc. cannot control inflation/contraction by fiat. The EXISTENCE of "money", how much exists, depends on its circulation in the economy. ___ 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
On Sat, 18 Jun 2022 at 03:45, Michael or Penny Novack < stepbystepf...@comcast.net> wrote: > > > 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 I don’t suppose it would be rocket science for someone to produce a patch file that substitutes the name of some obscure currency for BTC. I expect one would need to patch the XML file before upgrading to a new version of GNUcash, but this should be doable. At least with a Linux system, it should be fairly straightforward to create a script to do this. 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 ___ 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 > > > > > > > > > > To: gnucash-user@gnucash.org > &
Re: [GNC] Bitcoin Lightning payments
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 p...@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 >>> > >>> 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
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
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
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 ___ 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.
