On Thu, Jul 24, 2014 at 2:38 PM, Joseph Anthony Pasquale Holsten < [email protected]> wrote:
> On Jul 24, 2014, at 10:57 AM, Martin Blais <[email protected]> wrote: > > On Tue, Jul 22, 2014 at 8:57 PM, Markus Teufelberger < > [email protected]> wrote: > >> This poses a few interesting opportunities but also potential issues: >> >> Bitcoin for example has until now close to 43 million transactions >> recorded [https://blockchain.info/charts/n-transactions-total] (and some >> of them are not easily decoded or meaningful, so it can be a bit of a >> hassle to account for them correctly, but that's besides the point). If >> there were a way to encode this dataset into ledger (e.g. transactions >> between "Bitcoin:1abcdaddress" accounts) and then referencing the >> transactions/addresses in your actual private ledger, this could be of use >> for additional validation of transactions you enter, something like having >> the entire transaction database of your bank so you can finally make >> sense/use of that transaction ID. >> > > Given the scale and the need for constant update, this clearly requires a > custom system. > Not a good idea to use command-line accounting for this purpose IMO. > (But maybe I don't understand what you're trying to do.) > > > The way I see it, this additional record (which is not really another > entry as there is no amount) is purely intended for verification purposes, > both for ensuring correctness of ledger entries, and for verifying no > entries have been missed. > Let's speak in Ledger terms: this is not another "posting" to an existing transaction, but rather, a "tag" that is associated to the Ledger transaction in order to identify a particular transaction in the list of Bitcoin history. It's an ID to build a two-way mapping between two data sets. Here are the two use cases I can see: > - audit ledger entries for correctness: iterating over entries in the > ledger, verify each has a matching entry in the block chain with the > correct value for credit, debit, amount and timestamp. This gives extreme > confidence the account record has no incorrect entries. > - audit ledger entries for completeness: iterating over each of the > accounts, then iterating over each entry in the block chain for the current > account, verify there is a ledger entry with the correct value for credit, > debit, amount and timestamp. This gives extreme confidence the account > record has no absent entries. > These are not use cases for Ledger if I understand; these are verification methods to attempt to reconcile the data living in two separate data sources (and I don't understand how replicating one data source in another format gives any "extreme confidence" that one has no incorrect entries). The use case I see is making transactions with Bitcoin and correctly replicating those transactions in a Ledger file to do the things that Ledger does. This is just like replicating the transactions from a bank account, except that instead of converting the contents of a CSV or OFX downloads, you are converting Bitcoin history. Would this be useful? Given that the Bitcoin history never changes (or does it not and is it what you're trying to verify?), it is reasonable to assume that the one-time process of pulling some of your recent Bitcoin history from its repo (or wherever that is stored) does not need to get verified further: you convert that into Ledger syntax, insert an appropriate unique id (in order to dedup later), and you're done. You have now replicated your Bitcoin transactions and can use Ledger on it like you would regular fiat money. When I was running a mining pool, each block we earned was composed of a > few thousand of debits to our users for the single block credit. Sometimes > those had a transaction record because the user requested immediate > transfer of earned credit, but usually we held many satoshi in trust for > our users to avoid transaction fees. > > So while it’s a nice a idea, there are definitely situations where bitcoin > isn’t going to give you everything you desire. You could use ripplepay for > those micro-transactions, but even if your transaction partners publish > their transaction record publicly, there is no guarantee you can perform > the completeness check (second use case) from above. > I think what you're trying to do is different than what I thought above: I think you're trying to use Ledger to implement some verification scheme. I don't know much about the ecology of Bitcoin tech - you're speaking Chinese to at least some of this audience with the preceding paragraph, including me - but if all you're interested in is some sort of local replica of transactions and you're not going to use "reg" or "bal" then you might as well just write a tight and compact little data store, in binary form, and some good old regular code, not store this in a text format that is designed primarily to be edited by humans. Just my 2c, -- --- You received this message because you are subscribed to the Google Groups "Ledger" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
