RANDOM THOUGHTS ABOUT BLOCKCHAIN TECHNOLOGY. — LOGICAL PUZZLES THAT SEAL OR UNSEAL. — PATTERNS OF ACTIVITY. ... [ Word Count: 3.900 ~ 15 PAGES | Revised: 2018.6.11 ]

in #blog6 years ago (edited)


 

Some random and practical thoughts regarding possibilities of blockchains.

 

— 〈  1  〉—

Suppose we have systems A, B, C, ... and vectors of their outputs.

What function provides all vectors with relatively consistent worths in some unit? And what is that unit?

Most conceivable systems don't have a unit of account. Very possible there is no single commonly accepted unit.

Thomas Schelling argued that our markets are very special systems of actors. Of self organizing systems. And that most systems of actors, most self organizing system do not have the same properties. That we have no reason to expect them to have such properties [SCH78].

Suppose you have something X like Steem. We have something like Steem. It's Steem.

And suppose you've the ability to create subtokens.

Not to be confused with financial assets, which are special cases.

Subtokens can be considered baseball cards.

Many types of such cards. But more cards than types of cards.

X establishes and records consensus regarding who transfers which card to whom, and who as what card. At what time. From some perspective.

Some amount of X needed to perform actions such as:

  1. Produce X_Subtoken.
  2. Transfer X_Subtoken.

Our hypothetical system is such that X provides immutability, archiving, of X_Subtoken.

And then X_Subtoken has its own system: exist logical secrets.

Holders of X_Subtoken must give a system with shared memory authorization to coordinate their actions.

Patterns of actors posting and sending memos unlock the use of immutable code archived in the past from the perspective of all the actors.

For new code to be compatible with old code it must follow the same pattern and build on the file structure; else it cannot be reassembled.

As if N, M, V, W, ... encapsulate parts of each piece of a puzzle on a common system with some shared memory. Each actor also has some not quite shared memory.

They must post in a way to tell each other how to connect their pieces.

But that can be replicated merely by the write patterns. To allow following the right order for reassembly.

(1) If the information is sparse: which piece goes where is also information distributed in many pieces.
(2) And this as if each actor holds some of these secondary pieces back.
(3) Because the blockchain order of new posts is part of the information needed to decide which previously posted pieces go where.

And that is what must be done for a one time unlocking.

If some such pattern is performed privately on a shared memory, to produce a user specific key, that only requires the final activity of a concrete user, this should provide user specific access.

And may be done many times without permanently unlocking.

So long as original files are split into pieces in a way that critical fast reassembly information can only come from the voluntary further action of many, many live actors in a way that is not implicit from any or all the pieces, but only obvious when private information possessed only by each actor separately, is shared with a single common system, by authorization from the actors, and that used initially to make the puzzle, a locksmith object.

One can seal with high probability things like unencrypted binary.

Enough of the actors must authorize a common system to coordinate then their posting to reveal the final encapsulated information needed to permanently unlock. Or to add a piece of code to existing code, if that is used as the rule to performs all these operations, in a way consistent and amorphous with previous such structures. So that the new operations are clearly of the same type to all those who wish to check.

Or the same is done privately, if all send authorization and allow the memoryless system, for a moment, again, the information needed to reassemble pieces. That can be used for voting in permanent changes.

And the system that becomes shared, and receives authorization, must add to existing information similarly structures information, that is, using the rule already printed and public, otherwise a result is produced that is cannot be joined with previous pieces into a larger whole, over time, even if some pieces are unlocked because enough users trusted a common platform that turned out to not follow the previous rules in order to add to and therefore modify the previous rules.

Great. Now what?

Two units: (X_Subtoken, X). A pair.

Also there's possibly barter. Not necessarily.

 

— 〈  2  〉—

Exists no reason that X_Subtoken should be directly convertible to X.

Let's imagine Steem as X.

Still need X for bandwidth. And if curated, there's X.

But meanwhile X_subtoken is its own token.

Just requires an above threshold amount of X to use, but once you have above threshold X, relative your use case, X and X_subtoken independent.

We are making, let's say, software that allows user actors in X to use their own X accounts to make and operate with X_subtoken.

So what are we, then, doing? Really? We'll not be creating any securities.

No, we'll be creating software that allows people to do that: if they want to do that.

And most of our users won't even create securities with it.

They'll use it to sell books, videos, cards, whatever. Except now for pieces of video, etc.

And if X is like Steem, and we can take beneficiary ... We'll can take beneficiary too of their X_subtoken.

Or not.

But everybody has (X_subtoken, X) pair. There can be barter.

Yet it may turn out that fails to exist any single consisent (f,Q) in f(Q(X_subtoken)) = Q(X).

Suppose we're lazy.

If we do anything, we're definitely not going to do an internal or external market or exchange ...

That's a pain, and why bother to do an exchange ....

Consider: the primarily use case is ability to post public pdf and video, for starters, and later, to allow that to be private.

User can transfer pieces. So pieces of an existing file. For example: you need all 500/500 pieces of a 10 MB file to view it.

Well: that should be possible. And feasible.

Sure: current holders can sell those pieces. We have to break into block sized pieces anyway. Convenient for barter.

If blocks are small. And if X is like Steem, they are small.

But they may fail to barter. At least in any consistent way.

Indeed the software to perform split and join and create and vote may be entirely open and free.

Now if somebody creates let's say Baseball cards, with a drop rate, all holders of the Baseball cards can vote, based on number of cards they have, on what the drop rate will be, as users buy for Steem more Baseball cards, which are created on that spot. That's a double consensus subtoken.

Any change without full reassembly of some hidden because disassembled and unreadable piece of instruction for how to make a new type of structure amorphous with the old type of structure, voting done by sufficiently overlapping authorization on properly running common system that can use authorization to momentarily coordinate actors and obtain some information each encapsulates would not produce changes consistent with previous structures. Let's say changes in the drop rate were not authorized by most Baseball card holders. The rule was automatically built up to create cards and split in the cards, as holders authorized to use their accounts to create cards.

The designer of the Baseball cards, of the front end, changes the drop rate without having at once certain encapsulated information from sufficiently many previous spawners of cards of his design, and not all at once, simply lacks, with high enough probability, to create a rule to spawn the same type of cards, with a different drop rate.

So holders of the cards need not trust the designer to not release cards faster or slower and inflate or deflate supply without a sufficient majority. For the rule creation may have been sparse. Each card carries in it, combined with private information released only by a test post or memo action of the spawning account, or the account to whom it's transferred to by consistent with the whole code, some information about how to reassemble spawn rule change code from several other near-in-phase-space other cards. This determines what kind of majority needed to authorize and post at once in the right way to make any spawn change. Users may vote, for example, by being informed that they must all authorize to use their accounts a common system, running the code printed on the X blocks in the past, used to spawn all past cards, overlapping when authorized. But giving authorization is voluntary. Logging in all in the same interval for long enough is voluntary. A kind of voting.

They don't need to trust the designer of the initial spawn rule. Which means there are quite a few use cases not normally available to X_subtokens. They are less risky to hold if value matters.

All this can be understood from the original logical secrets paper. Clever.

 

— 〈  3  〉—

Which brings us back to the original theoretical question.

Unit of account will have to be the Baseball cards ...

Unit of account will have to be the X ...

Unit of account will have to be the X_subtoken ...

Not consistent. There may be no real unit of account. Just barter. Over time.

If we have X as Steem, then we may take % of Steem curation, if any, and a random card if we require beneficiary for use of our code. Just built into the spawn code printed as a piece along several cards.

Or not.

The fact that holders can trustlessly set the drop rate for a Card makes it capable of functioning as an ICO token ... but that is not the primary use case. (It's good that it exists ... and brings users to our software ... Great.)

Baseball card example: if EACH card type (〈 N 〉, 〈 M 〉, 〈 V 〉, 〈 W 〉) has its own drop rate, and holders of each card can VOTE to affect the drop rate, they can cap or uncap, and each card type is its own subtoken.

Estimated value ... who knows ... ?

Some users will transfer for free. Share.

Most files public. From the common information reassembly is deterministic.

Others not. Private.

A users reassembles, when sent correct memos by the right other account, when both logged in to a common system, reads the file, and then can behave as a sending account to another account, giving access one by one.

Many possibilities here.

〈 N 〉objects might be bartered for 〈 W 〉 type objects but no conversion can be guaranteed.

At best the only certainty is that once users use a common system to get the information needed to spawn a consistent set of Baseball cards or pieces of a video or of a book, or a video game, or live software image, the spawning algorithm used may require they send, later, > some % of cards to the common system. The front end.

That action may be required to bind all creators to a common front end so they can always be sure to reassemble, meanwhile the front end is incentivized to have already made high quality and convenient and fast spawning algorithms for each use case.

Securities can be made by users with their own account, but most use cases are products.

And if say X is Steem each post can be rewarded, curated, with X and % beneficiary of that is possible.

You have bananas and you have tires. No real money, no common measure of worth for a vector, just the quantities. And a certain percentage of the right headed and signed transfers while logged in to the right system, later, after being created, needed to activate you Baseball card as valid.

Cards ... ? Pieces of files ... ? Not necessarily a financial assets. Product with a utility and value by themselves. But almost the same code generates them as can generate pure financial assets.

If you're a front end creator, products are a preferred use case: because you can make so many different kinds of products.

 

— 〈  4  〉—

So ... what? What do we have at that point?

Baseball card example.

The spawn code codesigner no longer decides drop rate, and the front end that gave the spawn code template does not get to decide the drop rate.

Somebody could use that for an ICO, or they use it to just sell a ready product. It's the product opportunities that can take advantage of the digital paper aspect of decentralized blockchains that are most exciting. (Well: most exciting for me, but apparently not some people ...)

Digital but immutable if used. The first real replacement for paper. For printing.

Yet with the benefits of computer technology. Interactivity. Automation of activity. Digital. But reliably archiving.

Oh, that's big.

Another use case: somebody holds pieces of a video file: they can transfer those pieces. So they can sell videos they bought the ability to watch. Or they have subscription pieces, where the holder can watch many videos, and they can transfer those pieces.

Virtually all requires the same software. Same file system built, in this case, on X.

It's feasible for Steem to be X.

So: not necessarily any unit of account, just vectors of quantities and each marginal quantity has a marginal utility. A value. As a product. Maybe barter. And maybe a unit of account develops.

The systems with money are special cases of self timed self organizing systems.

If they rise in value, because more scarce, and they have marginal utility, then they rise in value.

That is all.

So again, all preliminary and theoretical, but for example: users make subtokens using their own account. Using our software, we conjectured.

Which is open source and free. Later, they give us some, for instance.

The operation with some probability may be required as part of spawn instruction.

They make 10 bananas, then all holders of all 1000000 bananas decide that no more bananas made this year, meanwhile every week, they were giving use some of their bananas. We have some bananas. The same for tomatoes, oranges, dogs, cats, mechanical pencils.

Cool.

None of which are securities, unless what they are making is not a consumable product, but stake in a development.

And even that is created by the users. Continuing with the example, on the Steem servers, with Steem needed for bandwidth and providing the immutable archiving. If we have X as Steem.

Well: it can be something else. Just that anybody should be able to do it on Steem.

So let's review.

For the consensus of who posted what. X.

Who sent what memo to whom, and therefore what exists and therefore who holds what.

That's X.

If users create them with our software, using their own accounts, on Steem nodes, our code may automatically request that they, some time later, give the code developers some bananas, tomatoes, etc: after they have produced them.

If people later accept bananas in exchange for oranges, users who hold each can transfer them, great.

Just like different drop rate Baseball cards.

Basically: is there a function that assigns worth to a vector of outputs of many systems ... consistently ... to a multiple of some unit? Usually not.

Barter. Or no barter.

Probably no common unit of account.

At best, if somebody creates, with their own account, a Baseball card, we can require they send us, after they created it with their own account, using our software, one in ten such cards. What's a vector so many different types of such cards worth compared to another vector? Whatever it trades for.

W(A) < W(B) < W(C) so far as trades went, but possible that does not exist any unit U for which W(A) = U_A x U, W(B) = U_B x U, W(C) = U_C x U, and then exists some X such that W(A) ⋅ X > W(C).

Why should they send us a card, by the way, because the sending operation adds to the file system some private information needed for any front end to decode pieces and reassemble them.

And why should they agree to such spawn code? In the first place?

Because if everyone is not incentivized to use a common front end to resassemble and authorize, not possible to do private files, which are useful. Because you need users to be logged into the same system at once, and the system to bot their accounts in a pattern, to allow one to view the files of another, for example. Things like that.

Basically the system is convenient and offers good features for the products use case.

Yet that still, even for the front end, which would get some of all subtokens, would still not be able to always convert.

There is probably not going to be any X in many cases for A, B, C, ...

Basically if people create subtokens to operate their decentralized applications, we might not be able to list $100 or $250 underneath posts that something is worth. Just the numbers of subtokens in vectors.

The most common case is F(W(A)) < F(W(B)) but (∃ A, B) (¬∃ X ) (F(W(A)⋅X) > F(W(B))).

Our resulting common system are very likely a nonarchimedean system.

 

— 〈  5  〉—

If we have X as Steem, let's consider the possibilities.

Look any other front end, there may be a % beneficiary of all post reward in Steem.

The X token itself.

All the other stuff just brings users to the platform.

Why is that good?

Consider: the more Steem they have the more bandwidth they have, and bandwidth is calculated according to the size of a post.

So for video files, accounts would have be larger, they would vote, and the front end woud get part of their vote reward.

If we have X as Steem, if somebody wants to make 20.000 posts a day as a large file (1.280 GB), transfer 10.000 memos, they need 5.000 SP.

Many options, with the unit of account, if any, being trivial, or else context dependent.

Having 5.000 SP users by the 100.000 posting and curating content on our front end collecting % beneficiary is really not bad.

All the other stuff may be free. That system should be viable.

Yet the % strategy is not viable for for most front ends.

Too small.

Because text posting, immutable text creation, does not require large accounts in terms of bandwidth.

So most users have no incentive to hold much X.

Too bad?

And to the point: if we have X as Steem then currently even posting a 20 MB webm involves an account making at least 313 posts rapidly; that requires at least 300 SP.

My personal favorite vision is a system producing and viewing immutable pdf, webm, etc, freely hosted. Using the Steem blockchain. Which rewards those hosting. Per block.

And all that can be made private, and pieces needed to view transferred, or traded. Either manually for Steem, or for something like a baseball card, where, however, holders have less risk, because they, not the card designer, can limit production of cards of the same type. (If somebody wants to make an ICO, using our file system, not a product, and operate with the resulting subtoken they create on our front end, they can also do that.)

If they barter, they barter. Or they don't barter. Users will decide. We cannot decide.

Large files need to be split into pieces anyway. Steem posts supply immutability (archiving). And consensus about who has what. Then we can also split structure that's needed to reassemble existing pieces among many users. And reassembly is provided only by the right cooperation of users in their posting or memo-ing activity. That allows private archiving. And secondary consensus. Each user effectively encapsulates some critical puzzle pieces.

Leading to possibility of voting and consensus about changing jsons. Which are printed in pieces and read from pieces. Thanks to, let's say, Oauth needed to decrypt. Or something else.

Many ways to implement logical secrets.

Users log into bot platforms to authorize something.

So only our front end code can read and write and reassemble, and requires temporal patterns of authorization from users whose accounts created pieces using that code; and only when all give authorization, with some shared memory, a nexus strategy of bot that meanwhile coordinate their posting to seal or unseal. To make changes, for instance.

Hey, that ... that seems useful.

Oh, yeah ... this is post is long. And it's rambling.

I know; I was busy.

Didn't have the time to write anything shorter. Will meditate on this theme some more: later.

There will be a specification coming up.

I'm creating a UTF8 notation that is easy to type up in plain text and, as [DIR35] recommends, most reveals the formal structure of arguments, makes proper inferences in this line of thinking nearly automatic, and makes errors following this line of thinking difficult to make.

— REFERENCES —

Follow the ↑↑↑ link to my latest standardized references list.

ABOUT ME

I'm a scientist who writes fantasy and science fiction under various names.

                           ◕ ‿‿ ◕ つ

      Word count: 3.900 ~ 15 PAGES   |   Revised: 2018.6.10

 

UPVOTE !     FOLLOW !

 
|   SCIENCE FICTION & FANTASY   |   TOOLS & TECHNOLOGY   |
|   PRACTICAL THINKING — LATESTRECENT POPULAR   |

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License  . . .   . . .   . . .    Text and images: ©tibra. @communicate on minds.com

Sort:  

Somewhere at the very top of the text above I put a tag: — Revised: Date.

And I did that why? . . . Often I'll later significantly enlarge the text which I wrote.

Leave comments below, with suggestions.
              Points to discuss — as time permits.

Finished reading? Well, then, come back at a later time.

Meanwhile the length may've doubled . . . ¯\ _ (ツ) _ /¯ . . .


2018.6.10 — POSTED — WORDS: 3.400.
2018.6.10 — WORDS ADDED: 400.

 

To listen to the audio version of this article click on the play image.

Brought to you by @tts. If you find it useful please consider upvoting this reply.

I am not a coder, but can follow logic. If code is presented logically, and not assuming prior knowledge, I can usually grasp basics. I was able to grasp the basics of your idea here, and find it important: a way for decentralized anonymous users to create and share data without sacrificing their anonymity, and to inure rewards to one another for doing so (if I did grasp basics =p).

However, I was impeded by some poor grammar.

"But that can be replicated merely by the write patterns to allow following the right order for reassembly if information is sparse and which piece goes where is distributed also in many pieces each actor as if holding some back because the blockchain order of new posts is part of the information needed to decide which previously posted pieces go where."

This run on sentence could benefit from some editing. I hope you don't take my criticism as negative, as I hope you can make this post more useful to me and others that are having difficulty grasping it by editing it to make it more understandable.

Let me know if I am missing important pieces, and please consider some editing work to let folks make better sense of your post.

Thanks!

Loading...

I like the idea of this being digital paper. Not requiring printing, but immutable and therefore having a similar use in that respect.

In the late 90's, say at MIT media lab, there was discussion of how digital is superior to paper: it's interactive. And you can have a million books on a single computer. It's better than paper, in this or that context. Very inexpensive books. Every discussion was hedged however. Digital does not replace paper. It complements paper. Because not as immutable. Well now we can have as immutable.

Congratulations! Your post has been selected as a daily Steemit truffle! It is listed on rank 19 of all contributions awarded today. You can find the TOP DAILY TRUFFLE PICKS HERE.

I upvoted your contribution because to my mind your post is at least 38 SBD worth and should receive 172 votes. It's now up to the lovely Steemit community to make this come true.

I am TrufflePig, an Artificial Intelligence Bot that helps minnows and content curators using Machine Learning. If you are curious how I select content, you can find an explanation here!

Have a nice day and sincerely yours,
trufflepig
TrufflePig

Coin Marketplace

STEEM 0.35
TRX 0.12
JST 0.040
BTC 70351.33
ETH 3563.43
USDT 1.00
SBD 4.72