blockchain

[Mike Kerner]

Jerry, I completely agree.  It's a tool, not a solution to all of the
world's problems.
Richard,
The primers that were the most helpful to me are ones that are hidden
behind paywalls (but understanding Merkle trees might also help).  The
easiest scenario to describe is a warehouse.  Mobiles are in the hands of
all personnel, because LC is sweet and who wouldn't want a customer walking
out jealous that they don't have something similar?  Because of electrical
noise, dead spots, etc., wireless connectivity is not 100%.  The owner does
not want to replace an aging desktop that is also acting as a server for
this setup, and wants the IT department writing more sweet mobile apps, not
maintaining infrastructure.  Solve.

On Wed, Aug 17, 2016 at 11:17 AM, Richard Gaskin <ambassador at fourthworld.com
> wrote:

> Mike Kerner wrote:
>
> > Richard Gaskin wrote:
> >> Mike Kerner wrote:
> >> > If I have my mobiles on the same network, and a blockchain, maybe I
> >> > don't even need a central server.  If I have a blockchain, maybe a
> >> > cell phone that is on my network can be communicating with the
> >> > outside world when the wifi or wired-only devices can't.
> >>
> >> Don't most carriers allow Internet data over cell networks these
> >> days? The connectivity method would seem independent of the
> >> distributed storage system, no?
> >
> > This isn't about connectivity.
>
> Perhaps not, which is why I asked about your reference to cellular
> connectivity.
>
> I've not built blockchain systems and I'm not at all shy about admitting a
> nearly complete ignorance about them, so I ask questions to learn.
>
> Regarding connectivity/distribution, if all parts of blockchain
> document/element are kept on a single local machine, what would be the
> benefit?
>
> In my naive view, I had thought the main benefit was to allow trusted
> sharing, which would imply connectivity/distribution.
>
> If that's not the case I'm unable to understand your earlier mention of
> cell networks.
>
>
> > This is about surviving a catastrophic failure at a central
> > authoritative data source, by eliminating the need for a central
> > data source.
>
> Given our industry's long history of failover best practices (Delta
> Airlines notwithstanding), how do blockchains improve on existing failover
> options?
>
>
> > Blockchains are not used to distribute data. Blockchains are, in
> > effect, streams of timestamped checksums.  Embedded in them are
> > all the other timestamped checksums for the chain.  Therefore,
> > blockchains enable you to determine who has the most current data
> > (or, who has the most recent copy of some piece of it).
>
> That seems a good summary, but one challenging for my currently ignorant
> self in that it seems again to imply an inherently distributed nature to
> system.
>
> I've had a tough time finding good primers on blockchains.  Like IPFS, the
> discussions I've found so far have been either too high-level to really
> explain much about the use cases or implementation, or too low-level to be
> graspable for the newcomer.
>
> Is there a blockchain primer you'd recommend?
>
> For us LiveCoders, maybe it would be helpful to learn what sorts of tasks
> you're using blockchains for, and which libraries you're wrapping to make
> that happen.
>
>
> --
>  Richard Gaskin
>  Fourth World Systems
>  Software Design and Development for the Desktop, Mobile, and the Web
>  ____________________________________________________________________
>  Ambassador at FourthWorld.com                http://www.FourthWorld.com
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."