Abraxas re-orgs by selfish mining and not releasing ephemeral data

[adambor]

I opened an issue in the original Prime repo (please read at least the 1st point), talking about possible problems with bitcoin PoW anchoring through anyone-can-spend.

Abraxas is especially affected by the 1st point mentioned - even if we put whole Abraxas blocks on the bitcoin mainchain in the clear (as taproot inscriptions), the miner controlling >51% of Abraxas hashrate can decide to not release the ephemeral data (transaction ids) - making the blocks unacceptable by broader Abraxas network and continue selfishly mining. At a later date he decides to release the ephemeral data and causes a re-org (since with >51% he will mine a longer chain), opening the doors for him to double-spend.

This means that an attacker with >51% of Abraxas hashrate can trigger large re-orgs and can double spend, therefore there is no added benefit of anchoring Abraxas to bitcoin mainchain, as it doesn't provide any more security than pure Abraxas PoW completely disconnected from Bitcoin mainchain.

I don't immediately see a solution to this issue...

One more input I can provide is that Abraxas full node mempools contain the transaction IDs associated with the seal ids, so one can try to deduce transaction IDs included in a block based on the list of closed single-use-seal specified in it, but this is not a clean solution, as miners can also include transactions received out of band, therefore no full node will be able to match the closed seal id to a transaction id, making it impossible for others to construct a PMT for the block, leading to rejection of such block by the Abraxas network.

[cryptoquick]

What if we use Prime to secure Abraxas?

[adambor]

That also wouldn't work, the problem is the data availability of the transaction IDs, and you cannot store that data on Prime by design - you cannot store anything on Prime.

One more thing to note is Abraxas and Prime use a different way to distribute PMTs (just different design choices). In Prime there is an interactive protocol between users and miners requesting their merkle proofs, while in Abraxas all the PMT leafs (transaction IDs) are released together as one bunch of ephemeral data, interested users then construct a PMT out of those leafs and compute their proofs.

Of course then in Prime you might have a problem of miner witholding the data for some people, for that you have the challenge window, where you can submit a challenge in the Prime block and the miner has to release the merkle paths in the clear otherwise he looses his blockreward - however this posses a problem where in case miner doesn't cooperate, the challenge will be very big (basically all the users will challenge) inflating the Prime block size to several MB and making it impossible to inscript onto bitcoin.

It seems like we need to find a solution where if you don't release PMTs in let's say 10 minutes after mining the block, the block has to be provably invalid (even if you release PMT data later).

[josediegorobles]

I think something like the last thing should work. If the PMT's are not release, is invalid. It's necessary to have always a clear source of truth in the bitcoin blockchain.

[adambor]

I think something like the last thing should work. If the PMT's are not release, is invalid. It's necessary to have always a clear source of truth in the bitcoin blockchain.

You mean this one?

It seems like we need to find a solution where if you don't release PMTs in let's say 10 minutes after mining the block, the block has to be provably invalid (even if you release PMT data later).

The problem is how do you implement such a thing without having to put whole PMT on bitcoin blockchain, One might think about OpenTimeStamps, but that has the very same issue - selfish miner can commit the PMT into OpenTimeStamps but not release the data to the public just yet, again waiting for some time and then cause a big re-org. There seems to be no other option but to publish the PMT data on bitcoin blockchain in the clear, which then kinda defeats the whole point of having ephemeral data.

[cryptoquick]

Is there a way to make a cryptoeconomic incentive for publishing the PMT? This is solved in Prime with a challenge... With Abraxas, maybe we can make a condition of the miner receiving ABTC that the PMT is available? Can we prove the PMT is ever not made available?

[adambor]

This is solved in Prime with a challenge...

I am not really sure that this even is a good solution. Imagine you have a very evil miner that doesn't release anything, you can then end up having a Prime block of the size of few GB, of people trying to punish the miner.

With Abraxas, maybe we can make a condition of the miner receiving ABTC that the PMT is available? Can we prove the PMT is ever not made available?

This is super hard to do. You would need oracles attesting to whether they saw the data or not, which is not good for decentralization.

I was thinking about probabilistic checking in subsequent blocks (e.g. every block would contain N random challenges requiring you to reveal specific leafs from PMTs in prior block), but that doesn't solve anything - as a selfish miner with >51% hashpower you of course would be able to pass all the challenges (because you know about all the PMTs, but no one else does).

I will look into ethereum's EIP-4844 which is used for exactly this purpose - keeping ephemeral data for a few days that is then discarded.

[cryptoquick]

Well, here's one thing about Bitcoin we should absolutely emulate: Miners can't spend their BTC until 100 blocks have passed. This is normal, they'll expect that. So, if we can do 100 probabilistic proofs before they can spend their ABTC, that should also be adequate.

[adambor]

Well, here's one thing about Bitcoin we should absolutely emulate: Miners can't spend their BTC until 100 blocks have passed. This is normal, they'll expect that. So, if we can do 100 probabilistic proofs before they can spend their ABTC, that should also be adequate.

That doesn't solve anything. Imagine you are a selfish miner with >51% of the Abraxas hashrate, so you just keep mining your fork submitting valid Abraxas blocks to bitcoin, but not publishing any PMTs. Because you haven't published PMTs, other Abraxas miner don't consider it a valid block and do a protocol reset with OP_RETURN and start mining on their own - you have chain split, one chain that is only valid for you (and will always be longer because you have >51% of hashrate) and another that is considered valid for everyone else. Then at a later date you release your privately mined chain to the public (with the PMTs) - this could be thousand blocks long and cause a very big re-org. With this you were successfully able to double-spend anything.

Probabilistic proofs don't matter, cause me as a selfish miner I will put them into my blocks and pass all the challenges, but again the whole network wouldn't know about them.

But we should IMO still keep the idea of probabilistic proofs open, as it forces all miners to store PMTs for some certain amount of time - but I would move that to another discussion!

[cryptoquick]

If this is just a problem with miners never publishing their proofs even once, maybe the solution is not to use an ANYONECANSPEND, but instead, to use a Prometheus multisig for the mining seal, and Prometheus could verify PMTs have been published.

Have we fully ruled out an ABTC solution? Maybe we add rules that the merkle root has to be verifiable to verify the block, and to do that, the PMTs are needed. And signature grinding could be added to enforce a certain level of PoW on L1, to reduce the possibility of 51% attack. Maybe we'd need to build in a difficulty adjustment, too.

[adambor]

to use a Prometheus multisig for the mining seal

This would turn the system into something like proof-of-stake, as Prometheus would be cryptoeconomically secured by funds on Abraxas (Maybe somehting like USDT), so the security of the whole chain will depend on this USDT bond/stake - not great!

Have we fully ruled out an ABTC solution? Maybe we add rules that the merkle root has to be verifiable to verify the block, and to do that, the PMTs are needed.

I don't see how this helps, delaying the miner's rewards to be redeemable only after 100 blocks - sure that's a good idea but doesn't solve anything, you just mine your selfish chain, mine like thousand blocks there, so as soon as you publish that chain and cause a re-org you can readily spend all the rewards from 1000-100=900 blocks.

And signature grinding could be added to enforce a certain level of PoW on L1, to reduce the possibility of 51% attack. Maybe we'd need to build in a difficulty adjustment, too.

Yes! This we should definitely do. The problem is that if Abraxas is susceptible to 51% attack even when doing the bitcoin PoW-pegging, we might as well be running it as a completely separate chain to Bitcoin. The only reason to anchor to bitcoin was to inherit it's PoW security, which we now see is unfortunately not the case (there is still possibility to 51% attack the network).

Another line of thought is to have no ephemeral data and put everything directly as an inscription to bitcoin blockchain. We would still keep the STARK proof & list of closed seals in a block, but also add txIds in the clear, those txIds could maybe be as small as 16 bytes for non PTLC transactions. Considering we use around 1MB of blockspace for STARK proof and list of closed seals, this leaves us with 3MB of space to put the txIds into, where in the best case we can fit ~190k txns (all txns normal - non PTLC) - achieving ~300TPS.

On a funnier note, we can also just put the ephemeral data onto BCH or BSV blockchain - finally some use case for those xD

[cryptoquick]

Liquid can store 10x as much, which gets us back to 1M. Could using Liquid with ephemeral data solve the problem? It would also solve the problem of what ABTC is, because it could be backed by L-BTC.

[adambor]

Liquid can store 10x as much, which gets us back to 1M. Could using Liquid with ephemeral data solve the problem? It would also solve the problem of what ABTC is, because it could be backed by L-BTC.

Well, that is basically just using trusted oracles (Liquid federation) to attest to the fact that PMTs were published or not. While I like Liquid, I don't think it's something we should depend on with Abraxas, it puts too much power in the hands of the pre-selected Liquid federation members - with no way for open participation for such a protocol. This is actually even worse than PoS! Because in PoS you at least have a stake/bond at stake which gets slashed if you misbehave, with Liquid you have nothing like that.

[cryptoquick]

I think I have a solution to data availability.

A CSPRNG is seeded with entropy from a hash of the block header prior. This then produces a number in the range of [0..2016], which is a block within the past two weeks, and [0..n], where n is the number of kilobytes of ephemeral data for that block. A Bao hash is a stream verification hash we use in Carbonado. Ephemeral data is verified in 1KB chunks. A certain number of 1KB chunks of ephemeral data are included in subsequent blocks as challenges to miners. If a miner fails that challenge, their pending ABTC is slashed. ABTC rewards from mining must wait 2 weeks to be spendable. If a miner fails a challenge, their rewards are slashed, and by slashed, I mean donated to the LNP/BP Standards Association.

What do you think?

[adambor]

So this goes into the direction of the other issue.

So let's say miner A mines block T Then miner B mines block T+1

Now there is a challenge in block T+1 to provide some ephemeral data from block T, right? Who is challenged here - miner A or miner B?

These challenges are nice to force miners to retain this ephemeral data (they cannot mine new blocks without it) and we should definitely have that!

However I feel like there still is 0 protection against selfish miners with >51% Abraxas hashpower, because that selfish miner will pass all the challenges - he is the only one producing all blocks in his fork, so he of course has all of the ephemeral data he needs to pass those challenges.

If a miner fails a challenge, their rewards are slashed, and by slashed, I mean donated to the LNP/BP Standards Association.

That we definitely should never do. Can you imagine ethereum slashing proceeds going to ethereum foundation?

[cryptoquick]

So this goes into the direction of the other issue.

So let's say miner A mines block T Then miner B mines block T+1

Now there is a challenge in block T+1 to provide some ephemeral data from block T, right? Who is challenged here - miner A or miner B?

These challenges are nice to force miners to retain this ephemeral data (they cannot mine new blocks without it) and we should definitely have that!

However I feel like there still is 0 protection against selfish miners with >51% Abraxas hashpower, because that selfish miner will pass all the challenges - he is the only one producing all blocks in his fork, so he of course has all of the ephemeral data he needs to pass those challenges.

Good point. What if we made it so any node relaying transactions needs to also pass this DA challenge, except the CSPRNG is seeded by entropy from a hash of the transaction and the last block header. This requires another transaction in the past 2016 blocks to be available in order to relay. So, a selfish miner won't receive new transactions to mine if they don't provide their past proofs in a sort of ... txswap marketplace, similar to the concept of bitswap in IPFS.

If a miner fails a challenge, their rewards are slashed, and by slashed, I mean donated to the LNP/BP Standards Association.

That we definitely should never do. Can you imagine ethereum slashing proceeds going to ethereum foundation?

Haha, fair.

[josediegorobles]

Ok, I don't know if this makes sense but if we make that the ephemeral data are part of the block for the last N blocks, with N large enough for making very hard make a reorg with only 51% Abraxas hash power?

One month is like N = 15000, so the last 15000 blocks retain the ephemeral data. Is going to be a non growable upon a limit part of the blockchain.

[adambor]

Good point. What if we made it so any node relaying transactions needs to also pass this DA challenge, except the CSPRNG is seeded by entropy from a hash of the transaction and the last block header. This requires another transaction in the past 2016 blocks to be available in order to relay. So, a selfish miner won't receive new transactions to mine if they don't provide their past proofs in a sort of ... txswap marketplace, similar to the concept of bitswap in IPFS.

I don't think this really helps, because of course the miner will pass that challenge (he has the ephemeral data himself - just doesn't release them). The problem is not the miner deleting the data, just not releasing all of them in the clear. The solution should be to somehow force the miner to release ALL of the ephemeral data in the clear and for the whole network to see that data.

[adambor]

Ok, I don't know if this makes sense but if we make that the ephemeral data are part of the block for the last N blocks, with N large enough for making very hard make a reorg with only 51% Abraxas hash power?

One month is like N = 15000, so the last 15000 blocks retain the ephemeral data. Is going to be a non growable upon a limit part of the blockchain.

Yeah, the problem is that we are limited by bitcoin block size, we need to put the whole Abraxas block into bitcoin as an inscription, so that means Abraxas block can be at most 4MB. And ephemeral data size per block can be as high as 24.5MB.

[cryptoquick]

Okay, what if anyone submitting a tx to the network needs to also include a transaction from the past 2016 blocks, from a CSPRNG seeded by entropy from the tx hash. To earn fees, the miner needs to release their proofs in order for it to pass consensus. This is a fees only network, the only way to make money is with fees, so the game theory should take that into account. Users need valuable data that miners have, and miners need users' fees.

[josediegorobles]

Ok, I don't know if this makes sense but if we make that the ephemeral data are part of the block for the last N blocks, with N large enough for making very hard make a reorg with only 51% Abraxas hash power? One month is like N = 15000, so the last 15000 blocks retain the ephemeral data. Is going to be a non growable upon a limit part of the blockchain.

Yeah, the problem is that we are limited by bitcoin block size, we need to put the whole Abraxas block into bitcoin as an inscription, so that means Abraxas block can be at most 4MB. And ephemeral data size per block can be as high as 24.5MB.

Ok, understand.

But really we need to put all as inscription? The abraxas block can have all the ephemeral data (and we get rid of them after X blocks). But not all is need to be as taproot inscription, isn't it? Or is a fundamental component? Equally every Abraxas node has to see if the new block is valid and if it's unscripted in bitcoin but for the last we don't need to test that is all there.

And btw, Abraxas is designed from zero, do you think is interesting to discuss apply solutions that was or are going to be implemented in other blockchains, for example, danksharding and zk rollups in ethereum (they have a long way to that becase ethereum is alive but if we start from zero we can apply similar solutions, maybe). In other issue, but I don't know if open that, only if it's interesting

[adambor]

But really we need to put all as inscription? The abraxas block can have all the ephemeral data (and we get rid of them after X blocks). But not all is need to be as taproot inscription, isn't it? Or is a fundamental component? Equally every Abraxas node has to see if the new block is valid and if it's unscripted in bitcoin but for the last we don't need to test that is all there.

Yep, seems like we unfortunately have to inscribe whole Abraxas block, check the issue I opened in original prime repo https://github.com/LNP-BP/layer1/issues/8

And btw, Abraxas is designed from zero, do you think is interesting to discuss apply solutions that was or are going to be implemented in other blockchains, for example, danksharding and zk rollups in ethereum (they have a long way to that becase ethereum is alive but if we start from zero we can apply similar solutions, maybe). In other issue, but I don't know if open that, only if it's interesting

Yep, definitely something we can think about! Best to open a separate issues/discussion for it.

I just feel like client-side-validation is superior compared to zk rollups & danksharding, that's why we are pursuing that design. Looking at ETH now, we can see that ~95% of all the transactions are actually just transfers & swaps - both can be easily done with a pure client-side-validated system (no need for global state).

[josediegorobles]

But really we need to put all as inscription? The abraxas block can have all the ephemeral data (and we get rid of them after X blocks). But not all is need to be as taproot inscription, isn't it? Or is a fundamental component? Equally every Abraxas node has to see if the new block is valid and if it's unscripted in bitcoin but for the last we don't need to test that is all there.

Yep, seems like we unfortunately have to inscribe whole Abraxas block, check the issue I opened in original prime repo https://github.com/LNP-BP/layer1/issues/8

Ok I think I have to see again all this thing

And btw, Abraxas is designed from zero, do you think is interesting to discuss apply solutions that was or are going to be implemented in other blockchains, for example, danksharding and zk rollups in ethereum (they have a long way to that becase ethereum is alive but if we start from zero we can apply similar solutions, maybe). In other issue, but I don't know if open that, only if it's interesting

Yep, definitely something we can think about! Best to open a separate issues/discussion for it.

I just feel like client-side-validation is superior compared to zk rollups & danksharding, that's why we are pursuing that design. Looking at ETH now, we can see that ~95% of all the transactions are actually just transfers & swaps - both can be easily done with a pure client-side-validated system (no need for global state).

Of course but what I'm thinking is in using that for having more seals and transactions, nothing more.

[josediegorobles]

Being a little more wild, if we have a hybrid proof of stake/proof of work. The miner who inscribes the hash in bitcoin blockchain propose the block to the validators. For stake you have to stake in bitcoin and in Abraxas at once, and with a clearly signaled way in the bitcoin blockchain. If the validators don't do their duty, are penalized in abraxas. The validators must cooperate with the miner in doing the bitcoin blockchain transaction. And all are compensated in abraxas. So we can make a way to determine if there are a new block of abraxas in every bitcoin block. If it's not valid the miner and validators are penalized and we search in the next block the new block. The worst situation is that many bitcoin blocks don't produce a abraxas block but a reorg is not possible so the miner wants to release the data.

[cryptoquick]

Okay, I think I have the right combination of incentives.

To create a transaction, a different, specific, pseudorandom transaction needs to be included from the prior 2016 blocks, as determined by the transaction hash. This cannot be known in advance, and this is a requirement for the network to earn more fees from users.

If a miner cannot provide that transaction, the wallet can detect fraud and submit a fraud proof transaction. If the miner does not refute the fraud proof by revealing the transaction within a certain time period, say, 6 Bitcoin blocks, their earnings are slashed for the past 2016 blocks. Miner earnings require 2 weeks to mature. This mechanism requires 51% consensus that the miner's earnings should be slashed. This does not protect against 51% attacks, and I'm not sure that's necessary for this to be a valid cryptoeconomic incentive. Also, this 51% attack would need to be sustained for two weeks in order for the funds to be spendable, which is plenty of time to detect the attack and find ways to mitigate it by bringing more hardware online.

If they do have the transaction, they need to present it to the network, and then funds remain safu. I considered having them reveal an entire block or even have the network reveal all 2016 blocks worth of transactions, but someone could DDoS the network by submitting fraudulent fraud proofs at little cost to themselves.

[adambor]

This does not protect against 51% attacks, and I'm not sure that's necessary for this to be a valid cryptoeconomic incentive.

But this is exactly what this issue is about! The main reason we want to anchor to bitcoin is to inherit it's double-spend (therefore 51% attack) security. There is no point in anchoring to bitcoin if it cannot protect us from 51% attack from Abraxas miners - we might as well run a completely separate chain to bitcoin (no anchoring) and in that case this issue is irrelevant.

I feel like the issue with miners not retaining the ephemeral data is already solved with https://github.com/adambor/The9thProofOfFolding/issues/13 - if you think that one is not complete, or there is some issue with it feel free to talk about it there.