Implement Proof of Fee (batch size-relative fee over-payment scheme) about sidetree

[csuwildcat]

I'm seriously leaning towards a basic proof variant: Proof of Bump - a simple algo that transaction anchoring nodes can use to pay more in fees for more ops. This is a far more benefitial strategy than Proof of Burn, and doesn't preclude later additions to operation-level proofing schemes.

[OR13]

The first objective of the PoW is to prevent spamming, here is a simple article regarding a naive implementation, I think it would be helpful to name a simple naive approach and complete the integration and tests using that algo before attempting a more complicated one.

I don't understand the comment regarding fees.

As I understand it, PoW in sidetree is only about spam protection, there is no block reward or transaction fees for the miner (batch writer).

Is there a relationship between the blockchain native tokens (BTC, ETH) and sidetree PoW?

Or is the proof a pure function of powAlgo, lastTransactionTimeHash , operationHash, and nonce ?

Will the PoW algorithm be geared towards existing hardware / miners or is it desirable for it to be asic resistant?

See also: https://swende.se/blog/Progpow.html

https://github.com/ifdefelse/ProgPOW

^ this complexity seems like a terrible idea for sidetree.

https://lhartikk.github.io/jekyll/update/2017/07/13/chapter2.html

^ this seems like a much better starting point.

I keep thinking about the case where a client wants to anchor their own operations, it costs them ETH or BTC to do this as well as compute time for PoW, additionally if their operations are invalid this is wasted.

The case is the same for sidetree nodes, but they are handling many operations, and doing much more work, so there is more chance for their work to become invalid while they try to complete a batch.

Can we walk through a simple case with block difficulty?

[csuwildcat]

PoW in Sidetree is just for spam, it's not tied to generating value or the actual target chain's own security system. The fee-burn idea, which I'm very seriously considering and will spec out to evaluate, is basically the same as requiring writers of large batches to engage in Proof of Burn, but instead you overpay txn fees in accordance with the amount of value a deterministic algo requires you to expend for the size of batch you're including. Instead of just burning BTC or ETH into a void, as traditional Proof of Burn does, you're doing the same thing - provably expending value - but at the same time upping your txn's fee, which has the dual benefit of putting your txn at the front of the line (loosely speaking). I've recently been thinking actual PoW algos are probably not going to net the same level of direct benefit/prevention, while being far more complex to implement, whereas 'Proof of (fee) Bump' might be relatively simple to implement and even more effective.

…

On Sat, Mar 30, 2019, 12:10 PM Orie Steele ***@***.***> wrote: The first objective of the PoW is to prevent spamming, here <https://cryptocurrencyhub.io/implementing-a-simple-proof-of-work-algorithm-for-the-blockchain-bdcd50faac18> is a simple article regarding a naive implementation, I think it would be helpful to name a simple naive approach and complete the integration and tests using that algo before attempting a more complicated one. I don't understand the comment regarding fees. As I understand it, PoW in sidetree is only about spam protection, there is no block reward or transaction fees for the miner (batch writer). Is there a relationship between the blockchain native tokens (BTC, ETH) and sidetree PoW? Or is the proof a pure function of powAlgo, lastTransactionTimeHash , operationHash, and nonce ? Will the PoW algorithm be geared towards existing hardware / miners or is it desirable for it to be asic resistant? See also: https://swende.se/blog/Progpow.html https://github.com/ifdefelse/ProgPOW ^ this complexity seems like a terrible idea for sidetree. https://lhartikk.github.io/jekyll/update/2017/07/13/chapter2.html ^ this seems like a much better starting point. I keep thinking about the case where a client wants to anchor their own operations, it costs them ETH or BTC to do this as well as compute time for PoW, additionally if their operations are invalid this is wasted. The case is the same for sidetree nodes, but they are handling many operations, and doing much more work, so there is more chance for their work to become invalid while they try to complete a batch. Can we walk through a simple case with block difficulty? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#25 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAICygdA_oJJU8IUuX_HP_Aq88IsMTUAks5vb7aagaJpZM4XNplv> .

[OR13]

I like this idea a lot, but it seems not to mix well with the current per operation PoW proposal. When writing the anchorFile, the tx fee or in ethereum case, gas limit * gas price, is a deterministic function of the size of batchFile, when querying the ledger, a node needs to get the transaction fee, get the batchFile, and check if the transaction fee is accurate, before accepting the batchFile, and its operations. This seems potentially dangerous, because an attacker could not pay the right amount, but a node would still be forced to download potentially large batchFiles to confirm this... but i guess thats always the case, a well funded attacker can anchor large and invalid anchorFiles and batchFiles, and the nodes will have no way of knowing until they try to resolve them. On the other hand, i really like the idea of not having the clients do PoW, and this solution will easily work for the case where a client wants to anchor their own operations directly. On Sat, Mar 30, 2019 at 2:40 PM Daniel Buchner <[email protected]> wrote:

…

PoW in Sidetree is just for spam, it's not tied to generating value or the actual target chain's own security system. The fee-burn idea, which I'm very seriously considering and will spec out to evaluate, is basically the same as requiring writers of large batches to engage in Proof of Burn, but instead you overpay txn fees in accordance with the amount of value a deterministic algo requires you to expend for the size of batch you're including. Instead of just burning BTC or ETH into a void, as traditional Proof of Burn does, you're doing the same thing - provably expending value - but at the same time upping your txn's fee, which has the dual benefit of putting your txn at the front of the line (loosely speaking). I've recently been thinking actual PoW algos are probably not going to net the same level of direct benefit/prevention, while being far more complex to implement, whereas 'Proof of (fee) Bump' might be relatively simple to implement and even more effective. On Sat, Mar 30, 2019, 12:10 PM Orie Steele ***@***.***> wrote: > The first objective of the PoW is to prevent spamming, here > < https://cryptocurrencyhub.io/implementing-a-simple-proof-of-work-algorithm-for-the-blockchain-bdcd50faac18 > > is a simple article regarding a naive implementation, I think it would be > helpful to name a simple naive approach and complete the integration and > tests using that algo before attempting a more complicated one. > > I don't understand the comment regarding fees. > > As I understand it, PoW in sidetree is only about spam protection, there > is no block reward or transaction fees for the miner (batch writer). > > Is there a relationship between the blockchain native tokens (BTC, ETH) > and sidetree PoW? > > Or is the proof a pure function of powAlgo, lastTransactionTimeHash , > operationHash, and nonce ? > > Will the PoW algorithm be geared towards existing hardware / miners or is > it desirable for it to be asic resistant? > > See also: https://swende.se/blog/Progpow.html > > https://github.com/ifdefelse/ProgPOW > > ^ this complexity seems like a terrible idea for sidetree. > > https://lhartikk.github.io/jekyll/update/2017/07/13/chapter2.html > > ^ this seems like a much better starting point. > > I keep thinking about the case where a client wants to anchor their own > operations, it costs them ETH or BTC to do this as well as compute time for > PoW, additionally if their operations are invalid this is wasted. > > The case is the same for sidetree nodes, but they are handling many > operations, and doing much more work, so there is more chance for their > work to become invalid while they try to complete a batch. > > Can we walk through a simple case with block difficulty? > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > < #25 (comment) >, > or mute the thread > < https://github.com/notifications/unsubscribe-auth/AAICygdA_oJJU8IUuX_HP_Aq88IsMTUAks5vb7aagaJpZM4XNplv > > . > — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#25 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AH6VsAaOsi_WwG5elyS9C5KH6j6zx1Teks5vb72pgaJpZM4XNplv> .

[csuwildcat]

@OR13 a few follow-ons to your response:

1. It is true that this does not prevent an attacker from anchoring a large batch of ops without paying the right corresponding fee, but nodes will know the correct fee before fetching and be able to cut off the processing if the file exceeds the expected size or is malformed after it is fully received. But as you mentioned, this is not introducing any new issue, given Writers can always attempt to violate the rules and observing nodes always need to apply them to minimize resource use and ensure they don't.

2. This does mean that at least this method of proof/anti-spam would need to be committed by the batch writer. However, this does not entirely preclude sender of an op from 'proving' the value of their included op by paying the writer through some out-of-band means. I had always hoped the long-run plan for Batch Writer cost deferral would be to integrate Lightning/Raiden, given repeated commits of small micropayments to a set of peer-writers you choose is a perfect use case for L2 payment channel utilities/protocols.

3. After thinking about the client POW, there just doesn't seem to be any feasible way to do it at this time that doesn't burden the user who must deal with the implied POW experience degradation on-device vs an attacker who has no such UX issue to manage. At this time, it seems like a better idea to just stack the chips against attackers economically and let them bang their head on the table.

[AlexITC]

Another idea for not downloading a possibly invalid huge file is:

• The IPFS file has a maximum allowed size, if we can abort the download if that size is exceeded.
• A single ION transaction can likely have a maximum size (possibly an estimation?), using the transaction fee can allows to estimate the maximum number of ION transactions in the file, the download from IPFS can be aborted if that's exceeded.

If there is a reliable/trusted way to get the size of an IPFS file, aborting the download should not be necessary.