You are reading content from Scuttlebutt
Feed of @ezdiy

this is me and my crayons, designing software in my armchair

@ezdiy
Re: %0vtC1GiAc

The most exciting part about wasm (and nacl prior to that) is that it can be decoupled from 20 years of web baggage and cut through 90% of web overhead, a fresh start. So the critical point of contention is - should wasm control the dom. And if so, why, really?

@ezdiy
Liked I'm starting to get excited about webassembly. It's low level. It has the s in #webassembly
@ezdiy
Liked We visited one of biggest eco-friendly :battery: located in the nature, [Dl in #traveling
@ezdiy
Re: %subgcpvsg

@ansuz

There is no "proof", in satoshian, offline verifiable proof sense, like there is no proof that some fiat token on-chain is truly backed by some security. You trust that other will defer to the authority of on-chain state. Meaning it is all subjective, but with singleton focal point - those who trust the singleton consensus have their own objective reality, while the others are cut out. Then it comes to which group is bigger.

Moving land registry on-chain is difficult, but not impossible - provided said land registry would be forthcoming to transfer their database to on-chain state.

But before you can do that, you still need to contractualize the whole of countrys legal system, otherwise you have no way to enforce laws on-chain, without resorting to some sort of backdoor (which would again recentralize it, and made the whole point of having a decentralized consensus moot).

So, I'd start from bottom up. How to digitize our justice? And is such a thing even possible?

@ezdiy
Re: %f9xdqPtVR

still good to have yarn, multiple implementations has a stablizing effect!

B-but competition is bad!

@ezdiy
Re: %ksFB43iqh

I should add that a related "split view" problem also exists in bitcoin, where it is called "eclipse attack" - attacker eclipses your perspective with false consensus. In bitcoin this is largely mitigated because only newly joining clients are vulnerable (and checkpointing makes the problem almost non-existent).

In SSB, simple flood network would help a lot to get coherent view.

I'm less and less convinced that replication as it exists now really needs to work the way it does. It is complex, slow, and computationally expensive.

Recently I've been playing with simulated models of pure flood network a'la bitmessage, where FOAF is used only to limit spam (ie you set some target message rate, and throttle people further afar). Each message records trust links en-route to prove social path it came from towards you. It's far less computationally expensive, as you don't maintain the graph and associated traveling salesman problem whatsoever, however the cost is constant (but capped) bandwidth usage.

@ezdiy
Re: %ksFB43iqh

What degree of consistency do you think we'd need here? do you think it would be enough to have a fork-proof that killed a feed?

Forks are easy (simply punish forks by collecting from people who trusted you, just like you punish excessive spending). The most problematic is consistency in time - basically when computing "credit gradients", at the moment you can't make any assumptions at which point in time they reside. Time in SSB is subjective, and simple collateral credit rating algorithms (where your underwriters are anchored at some point in time) need correct clock.

The way attacker exploits it is that they have a partial control over how far and where the feed spreads, because the network isn't perfectly connected - one can selectively create disperaging isles with drastically opposing perspectives standing in their own clique.

I can owe you yesterday, you owe me tomorrow, and everyone else should have at least semi-coherent idea which is it, and most importantly, that neither of us can introduce wide split-views of it by feeding the network selectively.

This becomes less of a problem with schemes like the visibility in post above, because the incentives align correctly (if you intentionally limit replication, you limit visibility to yourself...).

@ezdiy
Re: %ksFB43iqh

I was searching a term you used and this was first result: http://www.whatsonweibo.com/nude-pics-naked-loan-controversial-online-loaning-china/

Controversial as it may be, that is an excellent example of "social collateral". The only difficulty is how machine can determine the photos are of any worth :)

More realistic example is "attention economy" - while everyone could implement it subjectively, it would still have huge discouraging impact. Basically when your SSB client sees somebody is in negative a lot, it makes its feed less visible (a'la facebook).

The idea is that this would punish mainly celebrities (who'd be the ones with most underwriters in any case). If you as a celeb abuse your status to get cheap credit you don't repay, people will be less likely to spread your platform. It's a weak feedback loop, but at least there's one.

@ezdiy
Re: %ksFB43iqh

yes, well, there is always gonna be trust when dealing with any computer/idea space into realworld/meat space

The whole point of smart contracts is to remove the need for that trust in its entirety if oracle exists (the contract itself is executed on-chain, and consensus builders can individually consult the oracle), or at least minimize by enforcing a fidelity bond (escrow schemes) when a party defaults on their obligations when dealing with intrinsic fiat trust (craigslist with decentralized arbiters). But the moment you rely on naked trust alone, you're indeed back to standard banking with centralized trust arbiters and all. In short:

  • CC are better because you can have fancy contracts where many people can verify that something is true or not, and rubberstamp accordingly.
  • For example, if SSB had consistent feeds, I could write ETH contract where I pay you if you follow me, and it could be completely trustless. But as of now, this is impossible because SSB is not consistent, not even on feed level. So there is no oracle. If there is no oracle, we have craigslist, where:
  • CC remains completely unaware that there is some craigslist out there, it knows only that 3 people agreed to do escrow transaction, but doesn't need any context, it simply "trusts" the escrows.

Even full artificial intelligence would still need the concept of trust.

Any statistical scoring, no matter how smart, is still based on "history predicts the future" fallacy, it remains a naked trust, inherently flawed and exploitable. You'd create an adversarial learning race of machine learned statistical models. To that end, HFT finance works already a bit like that and it's not a pretty sight.

But if you want to have something deterministic, you can go back to basic sound finance. All you need is collateral, and a way to collect that collateral when somebody defaults in weakly coupled graph of escrows. In context of LETs, that means socializing the collateral and default risk - a clique will be taxed by strangers (when you transact with them) to a degree of insurance collateral - the more naked (riskier) someone's promise is, the more costlier it will become to transact for them. Another way to look at it is pooled insurance - when the network state taxes you because you trusted somebody you shouldn't, the burden is not as high because the whole group who trusted the defaulter serve as underwriters.

It should be noted that this is different from interest. Interest in modern banking is basically usury - the interest rate doesn't reflect default risk, but monopolistic pricing of credit access (ie banks charge high interest because only they have monopoly on IOUs). The risk for them is low simply because they have courts system to collect debts, the only real risk is of total market collapse.

In decentralized system, however, the credit cost would hopefuly reflect true risk of default, and everyone would need to collect interest in order to protect themselves whenever distant bonds unwind (due to network effects, you'll be paying this mandatory insurance almost all the time).

contract signatures, surely there is an easy way for a contract to verify that a transaction is sent to it, which implies a signature?

Ethereum uses secp256k1 ECDSA, not ed25519. It has an ecrecover (costs 3k gas I think) which can be used to verify arbitrary ECDSA. You can also inquire about the sender indeed, but that is not terribly useful to operate on external state (the whole point of having a contract).

@ezdiy
Re: %ksFB43iqh

@Dominic

I would be surprised if it made sense to implement ed25519 as an ethereum contract, but I figure they'd have a built in function to verify ethereum signatures though?

There is none, by design. The rationale is that this is good for generality - you count cost of individual field multiplications - and can implement any 256bit crypto you like, on another hand, it makes things a little more awkward than they need to be.

Then they DM me on ssb with their timespace coordinates, and I have my drone deliver the sandwich.

This is all cosmetic, though as I said before. Technically neither protocol deals with another, as you have no way to propagate the state. However SSB indeed makes a nice place for craiglist and to establish double escrows. However it can't enforce anything, it merely brokers trust one needs to transact in the first place, while the settlement still remains trustless.


Show whole feed
Join Scuttlebutt now