blockai-unofficial / openpublish-state-engine Goto Github PK

asset transfers

we need to add support for transferring shared ownership of registered works

we assume that 100,000,000 shares are issued in a registration

a transfer, using blockcast protocol:

{
  op: "t",
  sha1: "b4aa6221a47041628fa479e55a6246f39c527fe0",
  value: 10000000,
  ttl: 365 // number of days until the transfer is reverted back to the author
}

Now, in order for this to be a valid contract, both the person who is selling the shares and the person who is buying the shares need to sign the same transaction.

the person buying the shares is listed by which input index is theirs...

there will be two inputs, one for the buyer and one for the seller...

in the primary tx, there will be three outputs, one for the change from the buyer, one for the change from the seller, and the first blockcast OP_RETURN.

like the blockcast register process, there will be multiple bitcoin transactions, but everyone but the first will only contain change outputs and OP_RETURN data... only the primary tx will have the buyers signature, as the seller will be responsible for building the blockcast transactions.

previously I've talked about saving state, but having looked at bitcoin core a little bit, they seem to be using the "undo" approach, so perhaps when a block is orphaned or otherwise not used, we can "rollback" all the contained transactions in reverse to "undo" the transfers...

we could do it in a big postgres commit block for the entire block

80 byte, single transaction registration

we still support the current blockcast JSON

we just add a new, more space efficient version

SHA-1 is 20 bytes
BTIH is 20 bytes

then 20 characters (40 bytes) for just a hostname

so, and I've added returns so we can see the data, but obviously they wouldn't be

38c5f70998efac6d7d4f84dd7be90fc7df904ea7
b4aa6221a47041628fa479e55a6246f39c527fe0
bitstore.blockai.com

software can then construct the full link as:

https://bitstore.blockai.com/mqMsBiNtGJdwdhKr12TqyRNE7RTvEeAkaR/sha1/b4aa6221a47041628fa479e55a6246f39c527fe0

We always assume https://

We have the hostname

We know the registering wallet address

and we have the sha1

We then always build the same URL, so everyone will have to adhere to the same URI structure...

40 bytes of random bytes, followed by 3-40 bytes of ASCII will then be the protocol... magic numbers take up too much space!

name registration

we can consider the registration of a document to be a "preorder" in a name registration mechanism.

in order to claim the name, we publish a document consisting of the name key we are registering along with a signed nonce.

"IRC@williamcotton1shh2387h2f87h2873hd873hd8723h2", which has

sha1:638be8372f8cefe4d01c92d4406c71b91954d28b

then at least three blocks later, we blockcast

{
  op: "n",
  name: "IRC@williamcotton",
  nonce: "198273918723917293871927312",
  sha1: "638be8372f8cefe4d01c92d4406c71b91954d28b",
  signedNonce: "1shh2387h2f87h2873hd873hd8723h2"
}

the registration sha1 could only be created by signing the nonce.

the nonce is there to mask exactly what is being registered, until the reveal in the name command... like namecoin

hmmm...

what if the registration was just signing the "name" with a wallet? that masks the name and "has something that no one else has" (the ability to sign the name).

{
  op: "n",
  name: "IRC@williamcotton",
  sha1: "638be8372f8cefe4d01c92d4406c71b91954d28b",
  signedName: "1shh2387h2f87h2873hd873hd8723h2"
}

since this document has already been registered, it will be able to be transferred like any other Open Publish asset

I'd like to propose a method for scanning through blockchain data that involves the bytes of raw blocks/blk*.dat and bypasses the JSON-RPC.

Using a standard hex editor like HexFiend I loaded up the 133MB file blk00315.dat. I was then able to quickly scan through the data searching for the hex code0 x 2A 6A 28 1F...

The basic search pattern is 0 x 00 00 2A 6A xx 1F as the value xx following the 6A (the code for OP_RETURN) is the length of the OP_RETURN, and this is variable.

This technique would need to match and retrieve the full bytes that make up a transaction...

You'll notice that the previous output hash is reversed. This is a storage and parsing optimization, because the linked list flows backwards, so if you're scanning the bytes in reverse, you can save yourself from another operation.

This is another reason why blockcast-v2 should also store bytes in reverse...

It should be possible to scan through a .dat file backwards, and if the OP_RETURN data is positioned at the end of the transaction and in the last index, we would only need a single pass through the bytes. We should probably say that a valid blockcast piece needs to have only two outputs, the first being the change, the second being the OP_RETURN.

Speaking of reverse... instead of using the spendingTx id and scanning forward, blockcast-v2 should instead be based entire on previous output hash... so if "txid" of a blockcast-v1 is the "first" transaction, we'll make the "txid" of the blockcast-v2 the "last" transaction in a forward scan (which ends up being the first tx it would come across in a backwards scan...)