Share on Facebook
Share on Google+
Share on Twitter
Share on LinkedIn
JSON viewer for JSON database
I was looking to get a little done on the ethereum-classic-taxman accounting tool today, and thought a bit outside-the-box, what could I need in there that isn't a direct priority.The tool uses JSON databases, I switched a little while back because there could be security issues related to using a Python pickle database as the database backend.
An added benefit of using JSON is that its content is easy to view, and for example for debugging purposes, I thought it could be a good thing to have a tool that creates a view of the data that is easy to navigate and view. For example for debug purposes.
So I created this little script:
https://github.com/morphex/ethereum-classic-taxman/blob/main...
There are graphical JSON viewers on Ubuntu for example, but this little script can also have its output piped into a file, so that a database can be edited by hand in an editor. Or it could be piped to less on Linux/UNIX for viewing and searching.
On a related note, I saw some people lost their savings on the recent Luna/Terra crash. On the upside, I guess now is a chance to make a bet that the new variant with a massively higher amount of coins minted will succeed.
[Permalink] [By morphex] [Python and web (Atom feed)] [15 May 21:33 Europe/Oslo]
Ravencoin and ethereum (classic) accounting tools
So I've been hacking away at the accounting tool for ethereum (classic) today, adding support for converting the USD rate for ETH/ETC to another currency, based on data provided in the CSV format.It's mostly here:
https://github.com/morphex/ethereum-classic-taxman/commit/08...
I had to code my way around one thing in that respect, and that's because the USD-NOK rate for example is provided by the central bank, and they don't provide rates for Saturday, Sunday etc. So when transactions are made on days like that, the nearest, previous USD-NOK rate is used.
It seems reasonable to solve it that way, because something tangible (known) is better and more logical that whatever rate might come the day or even days after the transaction.
I also started work on another crypto currency accounting tool today
https://github.com/morphex/ravencoin-taxman/
Ravencoin Taxman. This takes a different approach from ethereum-classic-taxman, as it works with CSV data retrieved from a block explorer service. It doesn't download transactions and blocks from a node.
It takes much less (programming) time and (computer) resources to do it that way, but I also noticed that it was difficult to get CSV exports of ETC transactions on major / well known ETC block explorers today. This shows that it is useful to have a tool that is independent of for example block explorers, something that will work with just a node available.
The ravencoin-taxman code will need to have some crypto (RVN-USD) rate and fiat rates databases as well, I think I might just copy over most of the code for that from the ethereum-classic-taxman project. It doesn't seem like there will be much if any changes to those code bits in the future, and I don't see any obvious way now of making a package that will fit for both projects.
So I guess the only major bit left for both projects is getting the valuation (crypto currency * crypto currency rate in USD) combined with FIFO correct. That would pave the way later for example for tax reduction later, choosing the crypto-currency with the highest value when received for outgoing transactions. Which leads to less taxes due.
[Permalink] [By morphex] [Python and web (Atom feed)] [07 May 23:56 Europe/Oslo]
Some more work on an Ethereum (classic) accounting tool
So, I've hacked some more on the tool I'm building for accounting purposes.I guess since the last time I've posted on it, there are mainly two things I've been working on, one is valuation of crypto currency, the other is correctness of generated CSVs.
I've followed a simple principle when it comes to valuation of the crypto currency; and that is, first in, first out. Other options could be first in, highest value out, or first in, lowest value out.
It looks like in Norway, there is also the option of first in, whichever you want out; meaning you can receive crypto, and for tax purposes, choose which crypto currency you sell first. Which could be useful for tax purposes, to increase or decrease the tax owed due to dealings with crypto currency.
But it's a bit to keep track of, and I think I've gotten most of it done.
Another part however, is making sure the values in the CSV / Spreadsheet are correct, and I noticed that somewhere along the line of transactions, the account balance was off, compared to the state in etherscan.io for example. So I started looking, and figured out that it was due to a transaction that was registered, but didn't complete, because it ran out of gas. The max fee to complete the transaction was too low.
But as the transaction is still registered, you still have to pay the gas fee, so for that transaction, the value of the crypto transferred to another account is zero, and the gas fee still needs to be deducted.
You can see more about this on the go-ethereum issue tracker
https://github.com/ethereum/go-ethereum/issues/24768
there is also information in the commit:
https://github.com/morphex/ethereum-classic-taxman/commit/1a...
I think this shows, really well, how good Python integrates with the command line, and how easy it is to get something done in Python. A handful of changed lines, and it is possible to manually exclude a set of comma-separated transactions.
Of course this is also due to knowledge of how Python works, but yes, a great scripting and prototyping language Python is.
[Permalink] [By morphex] [Ethereum (classic) accounting data generator for Python (Atom feed)] [27 Apr 15:57 Europe/Oslo]
Ethereum (classic) accounting data generator for Python
Here's a python tool to generate CSV files suitable for accounting purposes, for incoming and outgoing Ethereum (classic) transactions:https://github.com/morphex/ethereum-classic-taxman
It will start with one main address, and then generate a CSV with transactions for that address, and one CSV for each address that receives ETH/ETC from that main address.
Crypto currencies were hyped up for a while, but given how much time has gone by, it looks like they are here to stay. I got some .com vibes from this crypto hype, but given that crypto currencies and related technologies will make finance-related activities such as loans cheaper and more accessible for the lender, and transactions in general cheaper and more flexible, there is little doubt left in my mind that it will work.
Betting on the right horse(s) is another matter however.
Regardless, taxes have to be paid, so I created this script that will connect to a geth/core-geth node and download all transactions related to a given address. I saw there were different services that offered x amounts of queries for y amount of money, and that's nice, but as a brogrammer and a small business owner I liked the idea of being able to be completely independent of such services.
The script comes with a test and test address 0x222f266B603e4fa6D5605b5ec1F1C86E35C19F7D (not owned by anyone I know), and running it generates the following CSV:
From,To,Hash,Value,Value USD,GAS Price ETH,Gas price USD,GAS Price Gwei,Block,Timestamp,Timestamp date,Timestamp time,Exchange rate
0x45d022c169c1198c29F9CBe58C666fc8D1Bb41f1,0x222f266B603e4fa6D5605b5ec1F1C86E35C19F7D,0xbdf64741321bf426aaf6c8903069b907335856c6a5756f0429d3f504d8b52cb0,0.806234,22.030682,0.000021,0.000574,1000000000,14671158,1646599200,2022-03-06,21:40:00,27.325415
Which looks right to me. I've also tested it against other ETH addresses and the calculations look correct. The precision of the last column rate was too high and it created a number which wasn't real, so just now I added a 6-point precision to floats generated in the CSV. This is also just enough to capture the standard low fee for ETC transactions.
[Permalink] [By morphex] [Python and web (Atom feed)] [03 Apr 10:21 Europe/Oslo]
A python script to calculate placement of poles for a roof
I've been working on the cabin, lately clearing out a tree behind the cabin that was a threat to the roof.Some blog posts about some of the work on the cabin here: https://blogologue.com/search?category=1591541232X85
Anyway, I need to setup some new poles for the porch / balcony, as there is a lot of rot in the parts below the roof, and those parts support the roof. So I can't just rip it out.
I wrote a script some time ago, and was going to use that today as I took finer measurements of the new beam that will carry the roof and how long an extended beam will have to be. As I was reading the script I couldn't make sense of it, so I re-wrote it, and posted a new one today:
https://github.com/morphex/misc/blob/master/holesforpoles3.p...
The old one is also in the same repository as holesforpoles.py, but you'll have to dig through the version history for that one.
I think it shows that in construction work, you have to cut once, measure twice, calculate thrice and maybe re-write the code quadrice. I wrote a holesforpoles2.py program today as well, but that was also discarded, more as a tool in the thinking process I guess.
[Permalink] [By morphex] [Python and web (Atom feed)] [13 Jun 17:14 Europe/Oslo]