I'm not aware of any way to do this ( balance of an address at specific time/block in the past ). It's an interesting question. "balance of an address" is a tricky thing to begin with. So at best I think you can achieve "best guess balance" anyway, unless you have the private keys for all addresses in question. Block explorers such as toshi and insight store do store balance information, but I'm not sure if they do it per address per block or only per address (all time best chain). |
|
|
|
|
dunno about the Vitalik quote but it just seems to me that bitcoin has reached the point of no return and simply is what it is.
In other words, I believe that consensus will never be reached on increasing the block size limit. AND THAT'S OK.
In fact, its better than OK. Because it demonstrates that the rules of the game cannot be changed mid flight. At least not for anything contoversial. If controversial changes could be made then it undermines trust in all cryptocurrency. Today block-size increase, tomorrow 21 mil increase, etc.
The consensus layer is just that. An agreement by everyone that's opted in to using bitcoin to date. Good luck getting all those people to agree on anything controversial.
So what to do about scaling? The first step is to admit to ourselves that bitcoin is what it is.
Say it. Bitcoin is what it is. The most we can do are non controversial soft-forks.
Given that, it leaves us with things like segwit, side-chains, lightning.
It also leaves us with alt-coins. Perhaps other coins have or will be devised with properties that inherently scale better than bitcoin. And/or that have fundamentally better privacy guarantees and decentralization incentives. If so, the market can dynamically shift to those over time. Very likely such coins would peg themselves to bitcoin anyway. Thereby lifting bitcoin's value should the altcoin have a mass-market breakthrough.
The time for major innovation in consensus critical areas is before launching a coin. not after. So it is important to get it right from the start.
Bitcoin is what it is. accept it.
|
|
|
|
|
I agree about the liability statement. Sure it's great for some full nodes (oracles) to exist with history since the beginning of time, but that's too much burden for average user as time goes on.
It seems to me that it should be possible to start/run a new node with only:
1) The utxo set starting at block X in the past. where X is at user's discretion.
2) the full TX history since block X.
Normally X should be something like a month in the past or at least a week to avoid problems with reorgs. If a reorg did occur that is deeper than node history then I suppose it should just stop and issue an error message.
Yes it requires some amount of trust since one is not downloading entire history. But it seems like the hash of each block and each corresponding utxo set could be distributed in enough places (peers, oracles) that one could be relatively certain. I mean it would be faster to connect and check with eg 500 peers/oracles than to download and verify the entire blockchain.
I believe this should be significantly faster for initial use than even a pruned node because pruned nodes still require a sync from genesis block for verification.
So what's wrong with this idea? I imagine that it or something like it has already been proposed. Does it have a name?
|
|
|
|
|
For local lookups of arbitrary addresses you could use btcd instead of bitcoind.
btcd has an address index. It needs to be enabled in your config with the addrindex flag. See the searchrawtransactions API.
|
|
|
|
Can the blockchain still be downloaded via http and/or torrent? I seem to recall that used to be possible, with some sort of published hash for verification...? The trick with any scheme like this (download or on usb/cd) is establishing trust that the blockchain hasn't been tampered with. There must be a simple way to verify via 3rd party tool(s). oh never thought about that but yes they could actually transform this into a business, by selling usb stick with a pre-filled blockchain
|
|
|
|
I have already experienced this. When I started coding up bitprices I was initially using a locally running instance of the toshi server. It took something like a month to get to May 2015 and once it started hitting the spam attack days, things just slowed to a crawl with some blocks taking 10+ minutes to verify and I soon realized it would never catch up at that rate. So I shut it down and switched to btcd instead. Toshi was running on a fairly beefy server: 16 core, 48 gig ram, Raid 1 7200 RPM. It turns out the limiting factor was the disks and SSD is now recommended for running Toshi. I realize this is somewhat apples and oranges with bitcoind. But I wonder if toshi would even keep up on SSD with 2+ mb blocks. The Blockchain Size Download Speed Singularity = The blockchain itself is so big, that it is impossible to download it all from the start, and by the time you download it, it grows even more.
|
|
|
|
|
It sounds useful to me as a power user feature. The change address linking has always bothered me.
It is less powerful than complete coin control, but adds a useful level of convenience/automation.
Also, it seems pretty simple to implement for the command-line. Eg, the sendtoaddress API could be modified (or wrappered by an external script).
afaik, there is no tool available for using coin control (selecting inputs) on the command-line.
More thoughts:
* If there are N transactions it may be useful to have m change addresses, where m is random. Just to add variance.
* Ideally the change amounts would resemble the non-change amounts. ie similar both in quantity and number of digits.
* this is orthogonal but the software could also have a mode that attempts to send without any change address. eg, it could prompt the user that the best match from available inputs is 1.234 BTC when the payment amount is 1.1 BTC. Send without change: Yes/No? A limit could be supplied so it would auto choose Yes if the difference is under the limit.
|
|
|
|
|
thx for the report. yeah single address is a simple case and I wouldn't expect any issues.
It gets more involved when dealing with all of a wallet's addresses including change addresses and detecting intra-wallet transfers. Particularly when multiple inputs (vin) are used in a transaction.
The main things to verify are that:
1) the report totals are the same whether --disable-transfer flag is present or not. If they ever do not match, that would indicate a bug.
2) The total of the BTC amount column should match your wallet software's present balance. For this to work, bitprices must be supplied with *all* of your wallet's addresses, including change addresses.
Along these lines, I'm actually looking for more real-world test cases.
If anyone has a set of wallet addresses from an old (maybe empty now) wallet you can share, that would be helpful. You can PM me with them, or post, whichever. If it's an HD wallet, just provide the master XPub. Please include the final balance as reported by your wallet software.
|
|
|
|
|
thanks.
Has anyone tried it with their own wallet addresses yet?
I'd like to get some reports of "yeah everything looks correct" or "hey I noticed a discrepancy".
|
|
|
|
I've introduced important new functionality in bitprices-v1.0.6. ( and mybitprices.info ) The default reports include movements into and out of your wallet only.In particular, movements to change addresses are not shown. This greatly simplifies the reports and makes them look more like a bank statement. bitprices splits rows where necessary to indicate 3rd party payments vs wallet transfers. In other words it does calculations to determine how much of each transaction went to wallet addresses vs to external addresses. The --include-transfer flag can be used to include the wallet transfers in reports. They will not be used in realized gain calculations (FIFO/LIFO) but will be included in column totals. A new column "type" has been added that identifies movements as "purchase", "sale", or "transfer". If desired, the legacy behavior can be obtained by using the --disable-transfer flag. In this mode, wallet transfers will not be detected and rows will not be split. This mode is useful for viewing exactly the inputs and outputs to each transaction, as they would appear on a block explorer. |
|
|
|
|
Thanks for the encouraging words.
|
|
|
|
I just announced it. Let me know your thoughts... I'm left curious about the details of the auditing tool you mention.
Feel free to share any details about that, if it's ready.
|
|
|
|
I should also note that the tool can use multiple blockchain API services. See the --api flag. Toshi, Insight and btcd are supported. btcd is the fastest and must be installed locally. btcd v0.12.0-beta or higher is required, as they recently accepted a couple patches of mine. thanks btcd guys! toshi and insight are comparable (slow for large TX) and may be installed locally or accessed as a 3rd party service (default). I submitted a pull request for a toshi optimization, but apparently it needs some more work before they will accept it. bitcoin-core can not be used unfortunately because it does not provide any API for looking up addresses external to the local wallet. By default bitprices uses https://bitcoin.toshi.io (3rd party service). The mybitprices.info website uses a local btcd instance for fastest lookups. Users concerned about privacy should use one of the local install options. |
|
|
|
bitprices is a command-line tool that generates transaction reports with the USD (fiat) value on the date of each transaction. As well as FIFO/LIFO disposal reports. A web frontend is available. I appreciate any testing, feedback, suggestions you can provide. GitHub: https://github.com/dan-da/bitpricesWeb Frontend: https://mybitprices.info/I initially wrote this utility to find historic prices so that I could provide these to an accountant. And it grew a bit from there. Let's see a couple examples, shall we? Price History Report./bitprices.php --addresses=1M8s2S5bgAzSSzVTeL7zruvMPLvzSkEAuv -g
+------------+------------+------------------+-----------+-------------+----------------+---------------+
| Date | Addr Short | BTC Amount | USD Price | USD Amount | USD Amount Now | USD Gain |
+------------+------------+------------------+-----------+-------------+----------------+---------------+
| 2011-11-16 | 1M8..Auv | 500000.00000000 | 2.46 | 1230000.00 | 188355000.00 | 187125000.00 |
| 2011-11-16 | 1M8..Auv | -500000.00000000 | 2.46 | -1230000.00 | -188355000.00 | -187125000.00 |
| 2013-11-26 | 1M8..Auv | 0.00011000 | 913.95 | 0.10 | 0.04 | -0.06 |
| 2013-11-26 | 1M8..Auv | -0.00011000 | 913.95 | -0.10 | -0.04 | 0.06 |
| 2014-11-21 | 1M8..Auv | 0.00010000 | 351.95 | 0.04 | 0.04 | 0.00 |
| 2014-12-09 | 1M8..Auv | 0.00889387 | 353.67 | 3.15 | 3.35 | 0.20 |
| 2015-06-05 | 1M8..Auv | 0.44520000 | 226.01 | 100.62 | 167.71 | 67.09 |
| 2015-06-07 | 1M8..Auv | 0.44917576 | 226.02 | 101.52 | 169.21 | 67.69 |
| 2015-10-17 | 1M8..Auv | 0.00010000 | 270.17 | 0.03 | 0.04 | 0.01 |
| 2015-11-05 | 1M8..Auv | 0.00010000 | 400.78 | 0.04 | 0.04 | 0.00 |
| Totals: | | 0.90356963 | | 205.40 | 340.39 | 134.99 |
+------------+------------+------------------+-----------+-------------+----------------+---------------+
Many more columns and also column templates are available for this report. Or specify your own columns in your own order. note: This address was chosen for the example because it is a well known address listed on theopenledger.com as having the largest transaction ever. Disposal ReportThis is a disposal report for the same address as above. Default cost method (FIFO) is used. ./bitprices.php --addresses=1M8s2S5bgAzSSzVTeL7zruvMPLvzSkEAuv --report-type=schedule_d -g
+--------------------------+---------------+--------------------+------------+------------+-----------+-----------------+
| Description | Date Acquired | Date Sold/Disposed | Proceeds | Cost Basis | Gain/Loss | Short/Long-term |
+--------------------------+---------------+--------------------+------------+------------+-----------+-----------------+
| 500000.00000000 Bitcoins | 2011-11-16 | 2011-11-16 | 1230000.00 | 1230000.00 | 0.00 | Short |
| 0.00011000 Bitcoins | 2013-11-26 | 2013-11-26 | 0.10 | 0.10 | 0.00 | Short |
| | | Net Summary Long: | 0.00 | 0.00 | 0.00 | |
| | | Net Summary Short: | 1230000.10 | 1230000.10 | 0.00 | |
+--------------------------+---------------+--------------------+------------+------------+-----------+-----------------+
Daily exchange rates are obtained from bitcoinaverage.com. All fiat currencies supported by bitcoinaverage.com may be reported, not only USD. Historic transaction data for each address is obtained from a blockchain API service provider, which can be either a third party service or something you run locally. plenty more info at above links... Disclaimer:Use at your own risk. The author makes no claims or guarantees of correctness. This software has not been reviewed or certified by a CPA. The schedule D report is provided for informational purposes only and may not be accurate or applicable to your situation. You should NOT present these results to tax authorities. Instead, consult with a tax professional. |
|
|
|
|
nice, hopefully someone takes this and makes a PHP lib for listening and interacting with the bitcoin p2p network directly.
anyone know if such a thing already exists?
|
|
|
|
cool, let me know how it goes. Thanks for the update. Will test later this evening and report back. Nice work!
|
|
|
|
This release adds the following features: - added --api=roundrobin option which will cycle through blockchain providers one address at a time to improve privacy.
- added --batch-size option for direct control over how large each address batch is.
- added --gen-only option to generate addresses without checking the blockchain if they have been used.
- added --type option to control which type of addresses are generated: receive, change, or both.
https://github.com/dan-da/hd-wallet-addrs/releases/tag/hd-wallet-addrs-v0.1.2 |
|
|
|
@btc_enigma -- Are you associated with blockonomics? I ask because I started working on integrating blockonomics API and ran into a roadblock. It appears there is not a suitable API available after all. The /api/balance method is close because it accepts multiple addresses and returns a balance. However, the balance can be 0 if an address has received funds and then sent them all, so what I actually require is total_received. Additionally for full integration, I really need total_sent. The other API's I'm using from toshi, insight, and blockchain.info do provide this info, and I make total_received and total_sent available as columns in the reports. Any chance this data could be added to the balance API results, or add a new API such as /api/addresses? thanks. Probably I will do something like "--round-robin=yes --batch-size=2" Yes, that sounds awesome ! Thanks . Let me know after the changes, would try to test your script |
|
|
|
|
Show Posts
