On Fri, Oct 24, 2014 at 1:44 PM, Melvin Carvalho <melvincarvalho@gmail.com> wrote: > On 24 October 2014 20:13, Daniel.Buchner <Daniel.Buchner@target.com> > wrote: > >> > I guess (on thin ice here...) that a receiver (payee) looks into the >> > distributed ledger for proof of transaction. >> >> "I doubt that anyone seriously expects a mobile app to store a whole >> block chain; in practice, a user of a blockchain system communicates >> with a specialist, reducing the situation to federation." >> >> The difference here is that the app in question could self-certify >> transactions with its own server using direct blockchain queries. The apps >> own server can install the bitcoind package and process confirmations >> itself. This is not a federated reliance on a large provider like >> Blockchain.info. >> > > Agree > Sure, this hypothetical app could join the federation to register its transactions (bitcoin transactions are certified using crypto keys, not central authentication) itself -- my point is that there is a line where this app would become a client of a service it is providing for itself, and for the purposes of division of roles in the standard general scripts. "Federation" as I used it in my comment means nothing more than what I meant by it, without the nuance Buchner appears to have imposed. Every running bitcoind instance is part of the federation of bitcoin providers: Bitcoin's barrier to federation is, to paraphrase Einstein, as low as possible but no lower. > > >> >> My main area of interest is in the user stories for developers and >> consumers. > > My main area of interest here is terminology/glossary.
Received on Friday, 24 October 2014 19:19:04 UTC