delete

[smooth]

Btw, has anyone paid close enough attention to the selfish-mining paper to observe that as the attackers hashrate approaches 50% of the network, his portion of the blocks won goes to 100%.  

You don't need to pay close attention. It is well known even without selfish mining that with 50+% you can reject all other blocks. I think Satoshi mentioned it.

Bitcoin often has a single pool with 50% of the network hashrate.

There is a fundamental problem here.

Agree

All the anonymity tech in the world is sort of useless against the state under this current situation.

Disagree. It is entirely possible the state has nothing to do with mining, nor will, and even with concentrated pools anonymity can still work. For example, perhaps the mining pools, even if concentrated, will jurisdiction shop the way the pirate bay does, or go more underground and become stateless (this could serve to decentralize them, since smaller pools are easier to hide). There are many such possibilities, not just the one guaranteed future of the state taking control of pools. That is certainly possible though.

We need to fundamentally rethink the longest chain rule as it is currently formulated.

Not necessarily. Another solution would be radically reducing concentration.

[1715209582]

1715209582

[1715209582]

1715209582

[1715209582]

1715209582

[1715209582]

1715209582

[TheFascistMind]

Anyway, can you say at least one real argument against removing RS under checkpoints ?

It isn't possible to independently verify the chain. This significantly elevates the trust model for checkpoints from choosing among valid chains to trusting that the chain below the checkpoint was valid before being trimmed. Again, tradeoffs....

The chain is verified by the fact that the block hashes are immutable. An attacker can't change the transaction data by even 1 bit and get congruence with the block hash history.

It is only a risk against an attacker that has 50% of the network hashrate and thus can rewrite the chain, but in that case you have bigger problems any way.

Thus afaics, TT's concern is BS.

[TheFascistMind]

Btw, has anyone paid close enough attention to the selfish-mining paper to observe that as the attackers hashrate approaches 50% of the network, his portion of the blocks won goes to 100%.  

You don't need to pay close attention. It is well known even without selfish mining that with 50+% you can reject all other blocks. I think Satoshi mentioned it.

Good point, but also note the selfish mining revenue equation shows that you get very close to 100% before you hit 50%.

All the anonymity tech in the world is sort of useless against the state under this current situation.

Disagree. It is entirely possible the state has nothing to do with mining, nor will, and even with concentrated pools anonymity can still work. For example, perhaps the mining pools, even if concentrated, will jurisdiction shop the way the pirate bay does, or go more underground and become stateless (this could serve to decentralize them, since smaller pools are easier to hide). There are many such possibilities, not just the one guaranteed future of the state taking control of pools. That is certainly possible though.

IMO very naive. But okay.

We need to fundamentally rethink the longest chain rule as it is currently formulated.

Not necessarily. Another solution would be radically reducing concentration.

Except that selfish mining starts at 25%, and creators of fiat can surely rent as much hashpower as they need when the time arises.

Your alternative would have to be very radical spread of mining. Wait, wasn't that what I've been suggesting...

[smooth]

Anyway, can you say at least one real argument against removing RS under checkpoints ?

It isn't possible to independently verify the chain. This significantly elevates the trust model for checkpoints from choosing among valid chains to trusting that the chain below the checkpoint was valid before being trimmed. Again, tradeoffs....

The chain is verified by the fact that the block hashes are immutable. An attacker can't change the transaction data by even 1 bit and get congruence with the block hash history.

The block hashes don't include the ring sigs. That's why the ring sigs can be removed without breaking the block hashes.

There is no assurance that there were ever valid ring sigs there, unless you were around to see it.

Among the trust assumptions here are that there weren't bugs in the code in the past that allowed invalid ring sigs to be accepted. But there are actually quite a few subtle assumptions that sneak in when you can't verify the entire chain.

[TheFascistMind]

Anyway, can you say at least one real argument against removing RS under checkpoints ?

It isn't possible to independently verify the chain. This significantly elevates the trust model for checkpoints from choosing among valid chains to trusting that the chain below the checkpoint was valid before being trimmed. Again, tradeoffs....

The chain is verified by the fact that the block hashes are immutable. An attacker can't change the transaction data by even 1 bit and get congruence with the block hash history.

The block hashes don't include the ring sigs. That's why the ring sigs can be removed without breaking the block hashes.

There is no assurance that there were ever valid ring sigs there, unless you were around to see it.

Afaik, the list of inputs and outputs are in the block hash. Only the proof that those inputs were signed for is discarded. No one can change 1 bit of those inputs without violating the immutable block hashes.

You don't need to have been around, because the longest chain rule assures you are looking at the consensus.

Zoid is correct.

(so who was spreading FUD again?)

[crypto_zoidberg]

.....
It isn't possible to independently verify the chain. This significantly elevates the trust model for checkpoints from choosing among valid chains to trusting that the chain below the checkpoint was valid before being trimmed. Again, tradeoffs....

It is possible but unreasonable because PoW prooves tx history anyway, with relation from current block till genesis.
Possible because i have  "not pruned" backup, so if i share it - it will be a natural prove. Isn't it ?

[smooth]

Anyway, can you say at least one real argument against removing RS under checkpoints ?

It isn't possible to independently verify the chain. This significantly elevates the trust model for checkpoints from choosing among valid chains to trusting that the chain below the checkpoint was valid before being trimmed. Again, tradeoffs....

The chain is verified by the fact that the block hashes are immutable. An attacker can't change the transaction data by even 1 bit and get congruence with the block hash history.

The block hashes don't include the ring sigs. That's why the ring sigs can be removed without breaking the block hashes.

There is no assurance that there were ever valid ring sigs there, unless you were around to see it.

Afaik, the list of inputs and outputs are in the block hash. Only the proof that those inputs were signed for is discarded. No one can change 1 bit of those inputs without violating the immutable block hashes.

You don't need to have been around, because the longest chain rule assures you are looking at the consensus.

Zoid is correct.

See edit above. You are trusting that the code that constructed that chain (i.e. accepted those inputs and outputs) worked correctly. That does not need to be the same code you are using today. You can't verify it.

Personally (and I'm pretty sure tacotime agrees) I believe that SPV-style approaches are far better, where it is possible to verify as much of the chain as you want, but not necessary to verify all of it to function, and fully verifying nodes still exist. Yes I am aware that an exact mapping of Bitcoin SPV does not apply, that's why I said SPV-style, not SPV.

[TheFascistMind]

Anyway, can you say at least one real argument against removing RS under checkpoints ?

It isn't possible to independently verify the chain. This significantly elevates the trust model for checkpoints from choosing among valid chains to trusting that the chain below the checkpoint was valid before being trimmed. Again, tradeoffs....

The chain is verified by the fact that the block hashes are immutable. An attacker can't change the transaction data by even 1 bit and get congruence with the block hash history.

The block hashes don't include the ring sigs. That's why the ring sigs can be removed without breaking the block hashes.

There is no assurance that there were ever valid ring sigs there, unless you were around to see it.

Afaik, the list of inputs and outputs are in the block hash. Only the proof that those inputs were signed for is discarded. No one can change 1 bit of those inputs without violating the immutable block hashes.

You don't need to have been around, because the longest chain rule assures you are looking at the consensus.

Zoid is correct.

See edit above. You are trusting that the code that constructed that chain (i.e. accepted those inputs and outputs) worked correctly. That does not need to be the same code you are using today. You can't verify it.

http://pandodaily.files.wordpress.com/2012/01/backpedaling3.jpg

[TheFascistMind]

Those ring proofs are still available (somebody is saving them) if we need to reconstruct from a discovered bug. In the meantime, no need to force everyone to download them every time we sync, which is a significant problem for XMR as I've read some users complain.

And if you think about how to radically decentralize mining as I have been doing for months, then you will realize a long download time for syncing is a significant issue.

(I repeat, "the jury is still out...")

[smooth]

Again, see edit above.

Imagine that a code bug exists where coins can be double spent in ring sigs, creating coins out of thin air. The developer realizes this, exploits it secretly, and then waits to see if anyone notices. He pushes out a checkpoint that throws away the old ring sigs and sometime later the bug is fixed.

Possibly it is discovered by someone who has an archived version of the chain, but even then, it can't even be independently verified that their claimed version of the chain is the correct one. Maybe someone else comes up with a different one. There are no hashes to refute this.

It is far better to retain the ability but not the requirement to independently verify the chain, and retain the chain somewhere in a trustless decentralized network.

Even committing a hash of the early chain (full hash including, not excluding, ring sigs) when you trim it would be somewhat better, but as far as I know is not being done.

The trust model of the BBR ring sig trimming -- within the chain itself and not relying on external sources -- is simply that everything is okay below the checkpoint because the developer said so and put a checkpoint there.

BTW, one last comment on this. I'm not even saying the BBR trimming is a bad idea. I see a lot of merit in it. I'm just saying that it involves changing the trust model, and is not unequivocally a good idea. It is a trade off. Nor do I agree that the only choice is between the current BBR implementation and the current Monero implementation.

[smooth]

Again, see edit above.

Imagine that a code bug exists where coins can be double spent in ring sigs, creating coins out of thin air. The developer realizes this, exploits it secretly, and then waits to see if anyone notices. He pushes out a checkpoint that throws away the old ring sigs and sometime later the bug is fixed.

Possibly it is discovered by someone who has an archived version of the chain, but even then, it can be independently verified that their claimed version of the chain is the correct one.

It is far better to retain the ability but not the requirement to independently verify the chain, and retain the chain somewhere in a trustless decentralized network.

Even committing a hash of the early chain (full has including not excluding ring sigs) when you trim it would be somewhat better, but as far as I know is not being done.

The trust model of the BBR ring sig trimming is simply that everything is okay below the checkpoint because the developer said so and put a checkpoint there.

BTW, one last comment on this. I'm not even saying the BBR trimming is a bad idea. I see a lot of merit in it. I'm just saying that it involves changing the trust model, and is not unequivocally a good idea. It is a trade off. Nor do I agree that the only choice is between the current BBR implementation and the current Monero implementation.

I completely agree with smooth here, the downsides of trimming the chain overshadowed the irrelevant time for syncing.

Sync time isn't irrelevant but it the choice between A and B is a false one.

Also the constant factor reduction might turn out to be relatively unimportant given other scaling factors.

[TheFascistMind]

Imagine that a code bug exists where coins can be double spent in ring sigs, creating coins out of thin air. The developer realizes this, exploits it secretly, and then waits to see if anyone notices. He pushes out a checkpoint that throws away the old ring sigs and sometime later the bug is fixed.

There are so many significant costs (if one realizes that without radically decentralized mining we are just wasting our time) that are paid for protecting that silly scenario.

You got sucked into defending a bad idea by the consensus of the XMR devs. It isn't your fault. You can't entirely speak your own mind.

[smooth]

Imagine that a code bug exists where coins can be double spent in ring sigs, creating coins out of thin air. The developer realizes this, exploits it secretly, and then waits to see if anyone notices. He pushes out a checkpoint that throws away the old ring sigs and sometime later the bug is fixed.

There are so many significant costs that are paid for protecting that silly scenario.

False. At best it is a constant factor reduction in the chain size.

[TheFascistMind]

(if one realizes that without radically decentralized mining we are just wasting our time)

See my edit.

Then again, I am not sure if ring signatures are even congruent with radically decentralized mining...

[xulescu]

Anyway, can you say at least one real argument against removing RS under checkpoints ?

It isn't possible to independently verify the chain. This significantly elevates the trust model for checkpoints from choosing among valid chains to trusting that the chain below the checkpoint was valid before being trimmed. Again, tradeoffs....

The chain is verified by the fact that the block hashes are immutable. An attacker can't change the transaction data by even 1 bit and get congruence with the block hash history.

It is only a risk against an attacker that has 50% of the network hashrate and thus can rewrite the chain, but in that case you have bigger problems any way.

Thus afaics, TT's concern is BS.

Everyone seems to assume that the difficulty is constant when it is actually an amazingly fast exponential. You don't need >50% of the hash rate to rewrite past blocks. On the contrary, most of the weight of a particular chain is in the newest blocks.

Those ring proofs are still available (somebody is saving them) if we need to reconstruct from a discovered bug. In the meantime, no need to force everyone to download them every time we sync, which is a significant problem for XMR as I've read some users complain.

And if you think about how to radically decentralize mining as I have been doing for months, then you will realize a long download time for syncing is a significant issue.

(I repeat, "the jury is still out...")

If everyone is not storing, then those who store will have an information advantage.

In XMR's present case, full nodes store everything.
In XMR's future case, full nodes store everything and SPV-style nodes store just a cache of what they need.

In BBR's present case, "somebody" stores everything and full nodes do not store rings.
In BBR's future case, "somebody" stores everything, full nodes do not store rings and SPV-style nodes are still required.

Do you see where I'm going with this?

[smooth]

(if one realizes that without radically decentralized mining we are just wasting our time)

See my edit.

Then again, I am not sure if ring signatures are even congruent with radically decentralized mining...

I disagree that a constant factor reduction in chain size will reliably give you radical decentralized mining. The constant factor gets overwhelmed by whatever super-linear scaling occurs, over a relatively small range.

[TheFascistMind]

(if one realizes that without radically decentralized mining we are just wasting our time)

See my edit.

Then again, I am not sure if ring signatures are even congruent with radically decentralized mining...

I disagree that a constant factor reduction in chain size will reliably give you radical decentralized mining. The constant factor gets overwhelmed by whatever super-linear scaling occurs, over a relatively small range.

You seem to offer some support to my second sentence then...

[TheFascistMind]

Do you see where I'm going with this?

No. Could you be more explicit?

[robinwilliams]

There are so many significant costs (if one realizes that without radically decentralized mining we are just wasting our time) that are paid for protecting that silly scenario.

market caps seem to agree with leaving the ring signatures in ... and i actually would prefer it as well.

it seems odd that anonymint who is the MOST CONSERVATIVE on EVERYTHING to do with anoniminity is siding on the side of possibly not being able to prove anoniminity of prev transactions.

[TheFascistMind]

Imagine that a code bug exists where coins can be double spent in ring sigs, creating coins out of thin air. The developer realizes this, exploits it secretly, and then waits to see if anyone notices. He pushes out a checkpoint that throws away the old ring sigs and sometime later the bug is fixed.

There are so many significant costs that are paid for protecting that silly scenario.

False. At best it is a constant factor reduction in the chain size.

We have another protection against that silly worry. It is known as "open source".