Tyler H [ARCHIVE] on Nostr: 📅 Original date posted:2018-04-20 📝 Original message: I like the efficiency ...
📅 Original date posted:2018-04-20
📝 Original message:
I like the efficiency your method brings and I'm also not that enthused
about bloating the blockchain with "non-financial data", however I do think
there's value in having the data live in the base chain, both from
accessibility and censorship resistance of the data to less additional
"networks". Already today any user that includes a commensurate miner's fee
can use the pushdata opcodes and add whatever data they want to the
blockchain.
One thing that the design requires is a separate method of communicating
bindings and not being censored - if it were onchain, a DNS lookup could
simply be no more than a light client requesting the relevant block.
I think anything that gets seriously far along will need to have some data
crunched and if only 100 users per day would fill up blocks then of course
constraints would necessitate other avenues.
Thanks,
Tyler
On Fri, Apr 20, 2018, 00:30 ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning,
>
> CLTV < unix epoch is for absolute lock time measured sanely in blocks,
> while > unix epoch is for absolute lock time measured in that arbitrary
> human-preferred unit called "seconds". I believe you mean CSV, as that is
> for relative lock time measured in blocks (but note that it has a special
> encoding, so you might be able to get 52560 precisely).
>
> The scheme as-is puts a lot of non-financial data onchain, which will make
> our bitcoin-dev colleagues cry. We can consider something similar to
> pay-to-contract instead, which is similar to Taproot (indeed
> pay-to-contract is the basis of Taproot)
>
> To create a Numerifides command, a user does the below:
>
> 1. Generates a secret private key p = random() and the public key P = p *
> G.
> 2. Encodes the Numerifides command (it could simply be a mapping "
> google.com = 127.0.0.1") as "command".
> 3. Computes the pay-to-contract public key: C = P + h(P || command) * G.
> This has corresponding private key c = p + h(P || command) that only the
> user knows.
> 4. Generates a P2WSH to the script: <52560 blocks> OP_CHECKSEQUENCEVERIFY
> OP_DROP <C> OP_CHECKSIG
> 5. Pays to that P2WSH on the Bitcoin network.
> 6. Broadcasts command, P, and the txid+outnum of the UTXO that pays to
> the P2WSH above, to the Numerifides network (not the Bitcoin network,
> Bitcoin cannot understand it).
>
> Numerifides network nodes, on receiving a command+P+outpoint, then
> verifies it by confirming that it can get C = P + h(P || command) * G, and
> that the outpoint is unspent, and pays to a P2WSH matching the above script
> template with the <C> replaced with the computed C.
>
> When the command expires (i.e. the lock time is completed) then the user
> can reclaim its locked coins from c = p + h(P || command), meaning it only
> has to memorize p and command.
>
> UTXOs that pay to the above construction that have expired the CSV will
> have the corresponding command deleted from your Numerifides database.
>
> If two commands conflict, then we simply prefer the one with higher locked
> amount (if equal, I do not know, your choice, maybe prefer the earlier
> one). And so on. What those commands are can be specified as you wish in
> your Numerifides proposal.
>
> If you insist on bringing in proof-of-work, the proof-of-work can be
> embedded in the "command" rather than on the Bitcoin blockchain. All that
> is published on the Bitcoin blockchain will be the point <C> (33 bytes) and
> a signature using c (64 bytes) plus a relatively small script, keeping
> bitcoin-dev happy.
>
> The same scheme can be used for practically any kind of asset I believe,
> not just names.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180420/f6e0172b/attachment-0001.html>;
📝 Original message:
I like the efficiency your method brings and I'm also not that enthused
about bloating the blockchain with "non-financial data", however I do think
there's value in having the data live in the base chain, both from
accessibility and censorship resistance of the data to less additional
"networks". Already today any user that includes a commensurate miner's fee
can use the pushdata opcodes and add whatever data they want to the
blockchain.
One thing that the design requires is a separate method of communicating
bindings and not being censored - if it were onchain, a DNS lookup could
simply be no more than a light client requesting the relevant block.
I think anything that gets seriously far along will need to have some data
crunched and if only 100 users per day would fill up blocks then of course
constraints would necessitate other avenues.
Thanks,
Tyler
On Fri, Apr 20, 2018, 00:30 ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning,
>
> CLTV < unix epoch is for absolute lock time measured sanely in blocks,
> while > unix epoch is for absolute lock time measured in that arbitrary
> human-preferred unit called "seconds". I believe you mean CSV, as that is
> for relative lock time measured in blocks (but note that it has a special
> encoding, so you might be able to get 52560 precisely).
>
> The scheme as-is puts a lot of non-financial data onchain, which will make
> our bitcoin-dev colleagues cry. We can consider something similar to
> pay-to-contract instead, which is similar to Taproot (indeed
> pay-to-contract is the basis of Taproot)
>
> To create a Numerifides command, a user does the below:
>
> 1. Generates a secret private key p = random() and the public key P = p *
> G.
> 2. Encodes the Numerifides command (it could simply be a mapping "
> google.com = 127.0.0.1") as "command".
> 3. Computes the pay-to-contract public key: C = P + h(P || command) * G.
> This has corresponding private key c = p + h(P || command) that only the
> user knows.
> 4. Generates a P2WSH to the script: <52560 blocks> OP_CHECKSEQUENCEVERIFY
> OP_DROP <C> OP_CHECKSIG
> 5. Pays to that P2WSH on the Bitcoin network.
> 6. Broadcasts command, P, and the txid+outnum of the UTXO that pays to
> the P2WSH above, to the Numerifides network (not the Bitcoin network,
> Bitcoin cannot understand it).
>
> Numerifides network nodes, on receiving a command+P+outpoint, then
> verifies it by confirming that it can get C = P + h(P || command) * G, and
> that the outpoint is unspent, and pays to a P2WSH matching the above script
> template with the <C> replaced with the computed C.
>
> When the command expires (i.e. the lock time is completed) then the user
> can reclaim its locked coins from c = p + h(P || command), meaning it only
> has to memorize p and command.
>
> UTXOs that pay to the above construction that have expired the CSV will
> have the corresponding command deleted from your Numerifides database.
>
> If two commands conflict, then we simply prefer the one with higher locked
> amount (if equal, I do not know, your choice, maybe prefer the earlier
> one). And so on. What those commands are can be specified as you wish in
> your Numerifides proposal.
>
> If you insist on bringing in proof-of-work, the proof-of-work can be
> embedded in the "command" rather than on the Bitcoin blockchain. All that
> is published on the Bitcoin blockchain will be the point <C> (33 bytes) and
> a signature using c (64 bytes) plus a relatively small script, keeping
> bitcoin-dev happy.
>
> The same scheme can be used for practically any kind of asset I believe,
> not just names.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180420/f6e0172b/attachment-0001.html>;