4 ms·

> except for the "open submission of transactions, with spam control using eStamps that necessitate the introduction of a whole economy into the system that it

> except for the "open submission of transactions, with spam control using eStamps that necessitate the introduction of a whole economy into the system that it doesn't otherwise require" part, ... Would you know of any projects around this idea? As far as I'm aware, "making spam costly" has always been the big kicker that has made every decentralized-permissionless-ledger project invariably include its own coin (and associated economy) to enforce that costliness. The only idea off the top of my head would be something like "PoW, but anyone adding data just pays the miners directly via some secondary market", which would still have pathologies of its own.

derefr 2y ago
I mean, a blockchain does have to be a blockchain to be a "distributed, permissionless, uncensorable, indefinitely-durable ledger." Blockchains are at a local optimum in their own design space. They're the Pareto-optimal form of the cypherpunk communication technology that started with Mixmaster remailers. If you want to send someone a truly-anonymous message through a dead-drop consisting of "the entire Internet", with no idea of how long it might take them to check it — then "a large, living blockchain network with many other people already using it for very mundane things, where you can stash your message in the extra-data of a transaction, or in its value, or in the address you're sending to, etc." really is exactly what you want. If that isn't your use-case, though — if you remove or weaken at least one of those design-space constraints — then things can change. For example, if the "ledger" in your use-case doesn't need to retain transaction history in a distributed, uncensorable, online state indefinitely; but rather can function with a history that's continuously being "offlined" past some finality threshold, converted into e.g. files in some agreed-upon format made available through BitTorrent (that have a bijective relationship with the data held in an archive node) — then you no longer need "spam control"; you only need "flood control." Compare/contrast: NNTP as a store-and-forward mechanism (needs spam control), vs IRC as a forward-and-forget mechanism (only needs flood control.) And flood control doesn't need eStamps; just much more boring infra-level solutions — node txpools that impose rate limits on messages buffered per peer and per signer per minute; validator nodes putting signers on a fail2ban-like temporary blacklist whenever a non-trivial fraction of their transactions are failing (and so wasting the validator's CPU-time); and so on. In such a system, you might want it to be expensive to generate a new signing key. IMHO this is an actually-valid use-case for Proof-of-Work: a one-time account-onboarding-time cost that serves as an anonymous equivalent to the barriers imposed by KYC/AML, making it so that spammers have to pay that fee again when blocked, and/or pay it O(N) times to send O(N) times as much spam (but where the spam is likely able to be recognized by signature and blocked with only O(log N) effort.) Essentially, if you aren't concerned with total spam accumulated over the lifetime of the chain, only with the rate of spam the network has to handle — then you can simply charge spammers (and transactors generally) in time, rather than in economic value.

derefr 2y ago

I mean, a blockchain does have to be a blockchain to be a "distributed, permissionless, uncensorable, indefinitely-durable ledger." Blockchains are at a local optimum in their own design space. They're the Pareto-optimal form of the cypherpunk communication technology that started with Mixmaster remailers. If you want to send someone a truly-anonymous message through a dead-drop consisting of "the entire Internet", with no idea of how long it might take them to check it — then "a large, living blockchain network with many other people already using it for very mundane things, where you can stash your message in the extra-data of a transaction, or in its value, or in the address you're sending to, etc." really is exactly what you want. If that isn't your use-case, though — if you remove or weaken at least one of those design-space constraints — then things can change. For example, if the "ledger" in your use-case doesn't need to retain transaction history in a distributed, uncensorable, online state indefinitely; but rather can function with a history that's continuously being "offlined" past some finality threshold, converted into e.g. files in some agreed-upon format made available through BitTorrent (that have a bijective relationship with the data held in an archive node) — then you no longer need "spam control"; you only need "flood control." Compare/contrast: NNTP as a store-and-forward mechanism (needs spam control), vs IRC as a forward-and-forget mechanism (only needs flood control.) And flood control doesn't need eStamps; just much more boring infra-level solutions — node txpools that impose rate limits on messages buffered per peer and per signer per minute; validator nodes putting signers on a fail2ban-like temporary blacklist whenever a non-trivial fraction of their transactions are failing (and so wasting the validator's CPU-time); and so on. In such a system, you might want it to be expensive to generate a new signing key. IMHO this is an actually-valid use-case for Proof-of-Work: a one-time account-onboarding-time cost that serves as an anonymous equivalent to the barriers imposed by KYC/AML, making it so that spammers have to pay that fee again when blocked, and/or pay it O(N) times to send O(N) times as much spam (but where the spam is likely able to be recognized by signature and blocked with only O(log N) effort.) Essentially, if you aren't concerned with total spam accumulated over the lifetime of the chain, only with the rate of spam the network has to handle — then you can simply charge spammers (and transactors generally) in time, rather than in economic value.