Anything concrete?

Reply to this note

Please Login to reply.

Discussion

Will has the right idea. The other thing is like renostr.

https://github.com/renostr

bitcoin uses this special construction of signature in order to save space, mainly, but it is also partly related to the principle of not using a secret key more than once (bitcoin address is a hash of a pubkey)

also, taproot is just a silly renaming of the principle of HD keys, which use a predictable sequencing that enables the wallet to scan for them

it's just an additional value concatenated to the secret to derive a new secret, and the purpose of it with taproot is to make it possible to have many related addresses without revealing to the network they are related, it's not even dependent on schnorr signatures, it could have been done the same way with ecdsa

the main thing to note here is that clients have to maintain state in order to keep a record of the tweaks, and that, once again, brings up two subjects:

- nip-42 to protect sensitive data (DMs and application specific data) from being disseminated and potentially cryptographically attacked - this would enable cross-client state with lowered risk of breach

- the idea of personal relays, specifically, application cache relays, which can be sent events via NIP-65 outbox model directly via correspondents (or over arbitrary proxy) which also facilitate p2p privacy for messaging and immediate reception of replies and whatnot

I think you are onto something. Remember that tweaks can also be references. And references can also reference state. Together with private relays you then have a turing complete web system. And you can also turn the relay from private to public with a switch. Powerful.

i'm sure more needs to be elaborated but i get it

Why stop at one tweak? Each subsequent tweak is a reference. You can have your own timechain in a time chain, with public and personal relays that you control.

indeed, the HD sequence is very primitive, you could use hash chains, these are very irreversible and only start from one state and are cheap to compute

or even combine the two with hash and HD sequence

Auditable. Tamper-proof. Privacy first. Decentralized. Turing-Complete. Smart contracts. Solves double spend. Integrates with nostr social. Propagaded by relays. And so on ...

but weak consistency

your system has to be tolerant of weak consistency

the (u)txo is the tie-breaker, the chain moves on, and everything syncs

that sounds expensive

Worth it for the value it creates, and there's also tricks to get the price down.

the consistency problem is probably not a matter you have deeply investigated, it's a big one, i mean, it's a 5 seconds dropping the thing and then hearing the plop sorta situation

i have dealt with several people and currently one of them mutes me over the subject of how difficult the consensus problem is, because i pointed out his scheme (in simple DST terms) lacked synchrony at all

I've investigated it extremely deeply. I use this all day every day, and have been for about 5 years. I've been deep in the weeks of sorting out consisteny problems, and do this often. But I consider it a feature not a bug. Having a (U)TXO as a single source of truth creates strong global consistency, with limitless use cases.

I have built and rebuilt the whole thing from scratch about 4 times. Each time it gets better. I can say that not only does it work, it's a joy to work with. You finally become sovereign and free from the algorithm. Nostr is the final touch which allows public and private realtime updates.

i'm not a fan of "single source of truth" the meme du jour, i'm sure you get why considering that this "singularity" comes from a massive distributed system wherein every node is verifying, i get how you can call it singular but it's not singular

i know that objective is a popular concept but it's not one that we can grasp with computation or sensing devices no matter how many we have, and pretending we can is hubris and dangerous

and every time i see this meme i cringe

it is an anchor, a point of reference, it is not truth, there is no truth in mathematics or computer science, and i would appreciate it if you would not abuse the language this way, because so many people do and don't even realise how abusive it is

what i will say, however, is that consistency does not need to be absolute for a system to work

bitcoin itself depends on a consistency that sets in after about an hour, on average, to become immutable, and the nearest thing to "truth" - it is basically infeasible that anyone with computation devices within any reasonable range of what we know is out there on our planet can beat, this is the "thermodynamic" equilibrium of bitcoin that is so compelling but you don't get until you understand and watch the system continue to aggregate computation capacity

in practice it's fine, because you have an observable track record that builds up with time

the only danger is RBF, but I think you can turn it off

you dont need 60 minutes to confirm because even if there's a reorg, the utxo chain remains a chain of digital signatures

now add to this the resilience of nostr, esp with public and private relays, plus ability to mirror state, with realtime updates, you can build a very good system, which is local first, but has global reach if you want it

in fact, to a degree, nostr was made to facilitate this use case, it's not something that was bolted onto nostr

then add onto that a market place of DVMs, or similar, that compete to offer services, including turing-complete web-scale smart contracts, and you have the most powerful system out there

i think the main issue is that people are not yet ready for this, they are still coming to terms with what taproot as identity, and nostr brings to the table, and advanced use cases are hard for some to see, and frankly scare others into opposing them, so much patience is required!

as the cost of transactions inevitably rises against the things they can pay for, this is not feasible... any anchoring system that works with the bitcoin chain has to be very very sparing, and 1 per hour seems to be kinda expensive in the million dollar per bitcoin scenario

consensus doesn't have to mean anchoring to bitcoin, and it doesn't have to be as strong as that, that is a very expensive consensus, and unique, i say it's especially unique, because it can't be replicated, Knut Svanholm has theories about it that are intuitions but it's just simple economics

the value of the data, and the decay of this value is everything

The market will set a price. Market participants will make trade-offs. For example some may with you use liquid, which also has taproot. While not as secure, it offers cheaper transactions. A group of nostr users or relays could run an Element server, and so on.

yes but what is the point of a consensus for a pubsub system?

the whole point is just best effort delivery of messages to interested parties, anything else is missing the point

a mechanism for creating E2EE DMs would be much more useful direction to query in - like, so, we have these schnorr pubkeys and schnorr signatures, how can we use this with taproot style tweaks and such to make it possible to have a stateless, metadata leakproof messaging protocol

now, you answer that one and you have actually solved a real problem

note that such a solution would have bearing on the brittleness of lightning network state channels

I am working on a chat system too, but I need other things in place first.

I see it the other way round. It's not a consensus system for pubsub. It's a pubsub system for consensus. Imagine global conensus, turing complete, infinite use cases, strong privacy, double spend protection, with a social aspect, and realtime updates.

That's what timechain + nostr gives you.

It's timechain + nostr. Not nostr + timechain. Hint: always has been.

nonsense

anyhow, i've been on record for a long time about how the bitcoin p2p network could use something better than the ad-hock rambling propagation pattern than it has, in order to create an intermediate staging consensus, a mempool consensus, i think i first started talking about it a year ago maybe

nostr protocol can do such a thing but it's overkill and it isn't a consensus it's just a propagation mechanism

https://arxiv.org/abs/1911.03291

this is much more like a possible thing to augment the mempool into an intermediate consensus

Well this is another different idea. But it seems fine in principle. Nostr could do checkpointing, for example. Why not.

An important aspect of bitcoin is that the emission was a level playing field. That has taken 15 years of track record, and millons of proofs. We are bout 96% done.

After emitting the coins fairly and as a level playing field, much of the hard work of consensus is done, the emission part. What remains is a robust ordering system. It is possible to innovate in that space, the harder thing would be to get universial consensus.

you need to seriously study distributed systems, i mean badly, i'm not continuing this conversation, you are throwing out every single naive idea that i had 10 years ago that doesn't work

What does work then? Show, dont tell.

if such a thing existed we would be talking about it, i never claimed to have the solution i just said that none of these things make one

Then it's just an appeal to authority from someone that has neither designed, built or used such a system, saying that something cant be done. Thanks for your thoughts, but we can agree to differ on that one.