Cassie Heart pfp

Cassie Heart

@cassie

1856 Following
277690 Followers


Cassie Heart pfp
Cassie Heart
@cassie
And not to overload with more protocol names, but DKLs19 has been superseded with DKLs24, but has tradeoffs as well with respect to bandwidth and compute.
0 reply
0 recast
1 reaction

Cassie Heart pfp
Cassie Heart
@cassie
threshold MPC for mobile phones and you want it to be fast, DKLs19 is the answer. The tradeoff that is important to know is that multiplicative based protocols use more bandwidth at signing time at the expense of less compute. (Though for ECDSA the consumption is negligible compared to most mobile apps)
1 reply
0 recast
1 reaction

Cassie Heart pfp
Cassie Heart
@cassie
Plain SSS is a trusted dealer protocol. There's other MPC based enhancements to it, like Feldman Verifiable Secret Sharing, which requires each participant that will hold a keyshare be involved at the time of key generation. This is important for creating additive based keyshares (protocols like GG20, CCGMP, Lin17 come to mind). Some protocols utilize multiplicative shares, which reduces the complexity of two party key generation to simple Diffie Hellman assumptions, and then has a multiplicative gadget used for the signature operations in a way to mask the k value (if ECDSA) so a party can't cheat and recover the key. DKLs18 is an example of this. DKLs19 is an interesting hybrid — it utilizes FVSS to produce keyshares, then has a gadget to convert from share types while performing the subprotocol from DKLs18 (with some adjustments) to thresholdize it. For mobile phones, if you want 2PC ECDSA, DKLs18 is the winner (though note that straight from the paper implementations will have a flaw). If you want...
2 replies
1 recast
1 reaction

Cassie Heart pfp
Cassie Heart
@cassie
I heard this song in your animation https://m.youtube.com/watch?v=I_izvAbhExY
1 reply
0 recast
1 reaction

Cassie Heart pfp
Cassie Heart
@cassie
/hard
3 replies
1 recast
46 reactions

Cassie Heart pfp
Cassie Heart
@cassie
depends on the scenario. if i was getting to the point where the system isn't scaling off PG alone it would be the "good problem to have" stage and the time to migrate off to dedicated infra. A lot of projects get too complex in design too early and spend more on infra than they need before they've sufficiently had enough traction to justify the engineering effort.
0 reply
0 recast
2 reactions

Cassie Heart pfp
Cassie Heart
@cassie
pgmq: https://github.com/pgmq/pgmq lightweight extension (basically just a query wrapper, the queue lives on postgres proper), nice semantics, performance difference is negligible compared to rabbitmq, with wayyyyy less headaches
1 reply
0 recast
0 reaction

Cassie Heart pfp
Cassie Heart
@cassie
test in production
1 reply
1 recast
6 reactions

Cassie Heart pfp
Cassie Heart
@cassie
I wrote a book on rabbitmq back in the day, just use postgres
1 reply
0 recast
1 reaction

Cassie Heart pfp
Cassie Heart
@cassie
noice
0 reply
0 recast
0 reaction

Cassie Heart pfp
Cassie Heart
@cassie
noice
0 reply
0 recast
1 reaction

Cassie Heart pfp
Cassie Heart
@cassie
noice
0 reply
0 recast
3 reactions

Cassie Heart pfp
Cassie Heart
@cassie
it's not my hand
0 reply
0 recast
3 reactions

Cassie Heart pfp
Cassie Heart
@cassie
Is there a breakdown of the operators of the validators signaling one choice over another?
0 reply
0 recast
5 reactions

Cassie Heart pfp
Cassie Heart
@cassie
The irony is perhaps mediated by the fact that permission itself is a composable resource, but wasn't well articulated in the current architectures of crypto. On even the basis of needs for upgradeability, proxy contracts were created. Other networks embedded upgradeability and disowning of applications as a reasonable shortcut. But the higher dimensionality of making the entire network able to reasonably express the equivalent to chown/chmod, well, that's the next step. I still hold that read/write/own is shortsighted, ownership is a feature to an application, the future is read/write/execute, and that simplicity begets a complexity that changes the web for good.
0 reply
0 recast
1 reaction

Cassie Heart pfp
Cassie Heart
@cassie
I don't believe it's due to lack of connections, it's the immutability factor. These networks are largely built as immutable structures, "code is law", including the consequences of people finding ways to "break the law", metaphorically or literally. This, combined with their limited "bandwidth" results in parallel systems built because frankly, why would Google adopt a permissionless smart contract driven approach to certificate transparency if an obscure selector bug let someone take over Google.com permanently? Being able to override these things are technically possible with the right code, but its layers of additional complication, for a language nobody outside of crypto uses, on a system that again, processes data at the speed of a 8088 on a good day. Fixing these problems is what wins over big tech. They do not care about principles of neutrality or decentralization, they care about their own objectives, and if they can't align, everyone from leadership to stakeholders will emphatically reject crypto.
1 reply
0 recast
2 reactions

Cassie Heart pfp
Cassie Heart
@cassie
it comes down to fork choice – if 70% of the network chooses a fork where reversal is a permitted state change, then 70% of the network is on a fork where reversal is a permitted state change, and 30% is not. Which one is the "official" network? That comes down to the conensus of users, ultimately. From the perspective of Quilibrium the company, if there is a _protocol-level_ vulnerability that resulted in loss, our position is to issue an alert, halt our own nodes, and issue a patch to resolve that. If there is an _application-level_ vulnerability, it is ultimately the decision of the application developers on how to handle, although for Q Inc-oriented operations like maintenance of the bridge code, helping stop the flow of compromised tokens is something we can help on. In short, it's grey – as is any situation where human consensus is a part of the picture. When the DAO hack happened, the majority fork chose Ethereum as it is today, the minority fork became Eth Classic.
0 reply
0 recast
1 reaction

Cassie Heart pfp
Cassie Heart
@cassie
1) Quilibrium is a decentralized protocol, to accept a non-standard transaction to consensus would require all node operators to agree to the change, which is very different from convincing a handful of validators 2) If an application amassed enough coin that a hack caused the same scale of loss on Quilibrium, the decision ultimately is in the hands of node operators, because even if core protocol had a reversal encoded in it, it would still have to be adopted. This project is more like bitcoin, so people should code accordingly.
1 reply
0 recast
3 reactions

Cassie Heart pfp
Cassie Heart
@cassie
Bear market usually comes decently after the top. This time is different by a long shot already — the believed bull market during the memecoin mania wasn't a bull, so the cycle is already broken
0 reply
0 recast
0 reaction

Cassie Heart pfp
Cassie Heart
@cassie
Not an indication or endorsement of license choice for the client, but I’m curious why you object to AGPL?
1 reply
0 recast
2 reactions