CryptoNote technical discussion and Chess Challenge

[XMRpromotions]

Good game by Nakamura today. Anand sacrificed a pawn and got pretty good play but suddenly his queen was under lock and key for 10 moves which gave Nakamura time to consolidate and emerge with an easy win.

That was a well played game by Namakura but I found Topalov vs Caruana much more entertaining despite it ending in a draw.
http://www.londonchessclassic.com/replay/games_gct.htm

In our game I vote for 37.Rd1

[1714835219]

1714835219

[TPTB_need_war]

This might not be an issue at all, but gmaxwell seems to imply here that there might be a vulnerability in the way segregated witness is implemented in BBR:

https://www.reddit.com/r/Bitcoin/comments/3vq8hm/multiple_new_bip_proposals_coming_up_on_day_2_of/cxpxi5t

Is this something to be worried about? Does it potentially impact other CryptoNote coins or just Boolberry?

All they are saying there is that if you want to prune the signature data, you need to still keep a hash of the signature data in the chain of hashes (of Merkle trees) for the blocks. In other words, you need to still be able to prove which signature signed which transaction, even if you've actually discarded the signature data.

I believe BBR already does the correct thing. And afaik, Monero does not discard signature data, but I could be wrong about that. If they do, I assume they would do the right thing as well.

BBR does not include a hash of the signature data in the blockchain. I'm not sure what exactly are the alleged vulnerabilities either, but I've always been uncomfortable with it, as I said way back in the 2014 BCX free-for-all thread.

Monero does not have any kind of segregated witness so no issue there.

I think the original motivation was to remove signatures from the data that is hashed so as to make the hash of the transaction (the TX ID) orthogonal to the signature data, so as to deal with malleability since due to the use of ECDSA there are two versions of the same signature that are equivalent (one of the reasons Wuille says he wants to replace them Schnorr signatures instead).

But then to do what they are calling a "segregated witness", the security model changes from every node verifying every detail for themselves, to every node assuming that some node will publish a proof-of-cheating if any activity was incorrect. In other words, these non-full nodes are able to maintain a UTXO (and thus aren't as dumb as SPV lite nodes) but don't verify every signature themselves. So in order to construct that proof-of-cheating, there must be a means to refer to which transaction on the block chain an invalid signature applied to which can be proven because of including a hash of the signature in the block chain. So in other words, malleability only applies until the transaction gets into the block chain. Once it is in the block chain, it is safe to hash the signature data and this enables segregated witness to function as intended.

Apparently BBR is including the signatures in the hash of the TX ID. Cryptonote doesn't have the malleability issue due to ECDSA because CN employs ed25519  which is an Edwards curve (variant of Schnorr). BBR isn't really doing a segregated witness. Rather BBR just discards signature data after assuming all full nodes had verified enough blocks of history. This is just checkpointing with lossy compression. Whereas, segregated witness is where all nodes don't verify the signatures and proof-of-cheating is used as the security model instead. Remember smooth, I had told you my design required a change in the security model.

However, I don't think Bitcoin can implement segregated witness correctly:

---8<---

One of the implications in my design is that propagation of data is crucial and thus an objective truth about who is not propagating has to be established. Afaics, this can't be accomplished with an adhoc P2P network where data propagates over several peer hops.

Wuille admitted this:

http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/segregated-witness-and-its-impact-on-scalability/

So your security assumption goes from not being sybilled, and no miner collusion, goes to "and I am not censored from other nodes which altogether do 100% validation" (for receiving fraud proofs).

This is a far-more scalable full-node or partial-full-node model that we could evolve to. It's a security tradeoff. It's certainly not one that everyone would want to make, but it doesn't effect those who wouldn't want that.

Which I think is why they are not proposing for segregated witness to exist without the current security model still in force. And I think once they dig down in DDoS, they will realize you can't mix the two.

This is why I say Bitcoin can't graft this on. It is stuck where it is. We will need an altcoin to start over from scratch. (well I've been wrong before about certain details, so wait for me to write a very detailed paper before assuming this is certain)

Note I had mentioned to you in private weeks (or months?) ago that I had discovered a way to restore the security model to equivalent of Satoshi's. I thought I had. But once I dug into the details of DDoS, I found issues.

Tifozi was guessing that letsplayagame (https://bitcointalk.org/index.php?action=profile;u=543579) might be Aronian not languagehasmeaning. Languagehasmeaning appears to be a good player but nowhere near the caliber of the people discussed as possibly being the OP of that thread.  I have never once seen languagehasmeaning claim to be a professional chess player.

Thanks. Believe it or not, I realized I had probably conflated the two users (I think it dawned on me when clicking the link in Tifozi's post), but as scatter brain and busy as I am on other work, I just didn't have the energy to correct. I wouldn't have even pointed this out (which is myself adding noise), except I can bury it here at this end of this other useful post.

[smooth]

I think the original motivation was to remove signatures from the data that is hashed so as to make the hash of the transaction (the TX ID) orthogonal to the signature data, so as to deal with malleability since due to the use of ECDSA there are two versions of the same signature that are equivalent (one of the reasons Wuille says he wants to replace them Schnorr signatures instead).

But then to do what they are calling a "segregated witness", the security model changes from every node verifying every detail for themselves, to every node assuming that some node will publish a proof-of-cheating if any activity was incorrect.

They are suggesting nothing of the sort. Full nodes in Bitcoin will still download the entire chain, including signatures. The peer-to-peer protocol will expect the signatures to be delivered along with the block and will then verify it using a hash stuffed in the coinbase.

They are suggesting to add a new sort of less-than-full node that is less secure than full nodes, but full nodes will operate under the same security model, just using a different method for fetching (and verifying) the signatures.

Apparently BBR is including the signatures in the hash of the TX ID.

It does not. BBR neither includes the signatures in the TX ID nor does it include an additional hash.

This is the interesting part, in that gmaxwell claims this introduces some sort of vulnerabilities, but it isn't clear to me what they are.

[TPTB_need_war]

I think the original motivation was to remove signatures from the data that is hashed so as to make the hash of the transaction (the TX ID) orthogonal to the signature data, so as to deal with malleability since due to the use of ECDSA there are two versions of the same signature that are equivalent (one of the reasons Wuille says he wants to replace them Schnorr signatures instead).

But then to do what they are calling a "segregated witness", the security model changes from every node verifying every detail for themselves, to every node assuming that some node will publish a proof-of-cheating if any activity was incorrect.

They are suggesting nothing of the sort. Full nodes in Bitcoin will still download the entire chain, including signatures. The peer-to-peer protocol will expect the signatures to be delivered along with the block and will then verify it using a hash stuffed in the coinbase.

They are suggesting to add a new sort of less-than-full node that is less secure than full nodes, but full nodes will operate under the same security model, just using a different method for fetching (and verifying) the signatures.

Which is what I wrote also:

Which I think is why they are not proposing for segregated witness to exist without the current security model still in force.

I did not suggest they were going to abandon Satoshi's security model. I explicitly stated they are not. Period.


As an additional tangential point, it is possible to get the benefits of using only segregated witness security model, while also still allowing full nodes to download the entire block chain. But Bitcoin better dare not do that, because as I pointed out, the Bitcoin network can't guarantee propagation nor assign blame when some proof-of-cheating doesn't propagate to an innocent less-than-full node. The implications are perhaps less severe in Bitcoin's case because it isn't attempting 1 second transaction confirmations and making PoW orthogonal to transaction confirmation. So when I say they better not do that, I mean (qualify my prior post) within the context of using segregated witness to maximize scaling of distributed transaction confirmation.

Apparently BBR is including the signatures in the hash of the TX ID.

It does not. BBR neither includes the signatures in the TX ID nor does it include an additional hash.

This is the interesting part, in that gmaxwell claims this introduces some sort of vulnerabilities, but it isn't clear to me what they are.

I believe Maxwell is referring to the inability of the segregated witness to construct a proof-of-cheating. And the implication is if you didn't do this historically, then you can't soft fork to add the segregated witness feature. But I didn't read Maxwell's comments, so I am just extrapolating based on the quick read of the one epistle fro Wuille I linked to.

Without a hash of the signature, there is no way to verify that a block chain was constructed with signatures, i.e. a 51% attack could steal coins. I presume BBR avoids this by enforcing that a fork from before a check point (where signatures were discarded) isn't allowed. Problem is even if someone saved the signatures, there is no way to absolutely prove that if a fork of BBR appears with greater cumulative PoW, that it isn't the valid one other than assuming the community and the lead dev can point to which checkpoints are the correct ones.

[smooth]

I did not suggest they were going to abandon Satoshi's security model. I explicitly stated they are not. Period.

Ah okay, misunderstood.

I believe Maxwell is referring to the inability of the segregated witness to construct a proof-of-cheating. And the implication is if you didn't do this historically, then you can't soft fork to add the segregated witness feature. But I didn't read Maxwell's comments, so I am just extrapolating based on the quick read of the one epistle fro Wuille I linked to.

His comments were linked above on this thread. Here's the link again:

https://www.reddit.com/r/Bitcoin/comments/3vq8hm/multiple_new_bip_proposals_coming_up_on_day_2_of/cxpxi5t

"uh. not having the commitment results in serious vulnerabilities, I would .. uh. suggest they add them ASAP ... "

[smooth]

Without a hash of the signature, there is no way to verify that a block chain was constructed with signatures, i.e. a 51% attack could steal coins. I presume BBR avoids this by enforcing that a fork from before a check point (where signatures were discarded) isn't allowed. Problem is even if someone saved the signatures, there is no way to absolutely prove that if a fork of BBR appears with greater cumulative PoW, that it isn't the valid one other than assuming the community and the lead dev can point to which checkpoints are the correct ones.

Well if someone can come up with valid signatures for one fork and someone else merely has a fork claiming to be valid but can't produce signatures, it is pretty clear which one will be more credible. I don't necessarily see a big problem here. That was crypto_zoidberg's argument, and for that reason he put the chain (with signatures) on a web site. Though I don't think it has been updated.

In Bitcoin it is already the case with UXTO pruning that if no one voluntarily saves the whole chain the system is pretty screwed.

I don't see "major vulnerabilities" here.

[TPTB_need_war]

Well if someone can come up with valid signatures for one fork and someone else merely has a fork claiming to be valid but can't produce signatures, it is pretty clear which one will be more credible.

Yeah except the longer fork could claim the signatures are missing. And they could be for UTXO that have not yet been spent on the other fork, so there is no way to show that one fork has signatures for those UTXO and the other doesn't. And you could have a bunch of valid signatures for recent time window wherein signatures are not supposed to be yet discarded. So then how do you prove those old UTXO were not signed for? You need for the owners of those UTXO to sign a message saying they didn't yet spend their outputs. If the adversary had some way to determine which UTXO are those where the private key has been lost, he could steal them this way.

Sounds far-fetched though.

I don't necessarily see a big problem here. That was crypto_zoidberg's argument, and for that reason he put the chain (with signatures) on a web site. Though I don't think it has been updated.

In Bitcoin it is already the case with UXTO pruning that if no one voluntarily saves the whole chain the system is pretty screwed.

I don't see "major vulnerabilities" here.

Re-reading the context where "nullc" commented (didn't realize before that username is Maxwell), I think he means in that in the context that BBR would be fully supporting a SW (segregated witnesss) with proof-of-fraud as the security model. Apparently Maxwell took peanutbuttercoin at his implication that BBR had implemented the SW security model, which in fact BBR has not really. So Maxwell's comment is due to a failure of communication as to what BBR has actually implemented.  SW security model requires proof-of-fraud, which requires being able to prove which signature was used for a transaction so it can be shown the signature was invalid in the proof.

Edit: someone might want to make a clarifying post on the Reddit subthread. I am not going to do it.

[smooth]

It sounds like we've gotten to the point of guessing what he meant, which is probably not too useful. Unless we can identify some specific serious vulnerabilities.

I do dislike the whole "My fork! No, my fork!" issue even if crypto_zoidberg (or whomever) can produce all the signatures. This is what I wrote a year ago:

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.

crypto_zoidberg disagreed at the time. I still don't know that it rises to the level of "serious vulnerabilities". Anyone interested can click through and read the entire exchange.

[TPTB_need_war]

It sounds like we've gotten to the point of guessing what he meant, which is probably not too useful. Unless we can identify some specific serious vulnerabilities.

The serious vulnerability exists if someone has implemented SW security model, because then no one can proof that a transaction was invalidly signed for. This is the inversion of the property of proving that all the signatures are valid. You can proof it was validly signed for, but not invalidly signed for. So that is the only possibility of what Maxwell could have meant. Thus we are not guessing what he meant. Reading that linked Reddit thread, he was clearly unaware that BBR had implemented SW, thus he took the word of peanutbuttercoin literally and said that if you have SW security model without hashes of the signatures, then you have serious vulnerability in your security model. But this does not apply to BBR, because BBR never implemented a SW security model.

Someone should post a clarifying remark at the Reddit thread so that Maxwell's comment isn't taken out of context. Most people won't realize the context within which he meant vulnerabilities could exist.

I do dislike the whole "My fork! No, my fork!" issue even if crypto_zoidberg (or whomever) can produce all the signatures. This is what I wrote a year ago:

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.

crypto_zoidberg disagreed at the time. I still don't know that it rises to the level of "serious vulnerabilities". Anyone interested can click through and read the entire exchange.

That is not the issue Maxwell was referring to.

Nevertheless, I agree that not putting a hash of the signature in the block chain is silly, because then you can never verify from an archive which fork has only transactions that were signed for. But this flaw is not the same as SW security model, because of the fact that BBR requires the valid signatures to be present and verified by all full nodes up to a large number of blocks of history (to the last checkpoint where signatures were discarded).

Even in my SW security model block chain design, I keep the signature hashes and it is still possible to download the entire block chain (of that node's perspective of the longest chain) and verify it. The Satoshi security model is retained in some sense. The differences revolve around the risk of being a less-than-full node. And I don't think Wuille fully comprehends yet all the issues. And the issues are different depending on the holistic block chain design. This is very complex, so I'll defer to a future white paper on this where I can more exactingly cover the various cases and details.

[smooth]

It sounds like we've gotten to the point of guessing what he meant, which is probably not too useful. Unless we can identify some specific serious vulnerabilities.

The serious vulnerability exists if someone has implemented SW security model, because then no one can proof that a transaction was invalidly signed for. This is the inversion of the property of proving that all the signatures are valid. You can proof it was validly signed for, but not invalidly signed for. So that is the only possibility of what Maxwell could have meant. Thus we are not guessing what he meant. Reading that linked Reddit thread, he was clearly unaware that BBR had implemented SW, thus he took the word of peanutbuttercoin literally and said that if you have SW security model without hashes of the signatures, then you have serious vulnerability in your security model. But this does not apply to BBR, because BBR never implemented a SW security model.

Nobody said that it implemented fraud proofs (which is what these proofs of invalidity are being called in bitcoin development). So maybe he assumed that, if so then incorrectly.

Segregated witness as proposed in Bitcoin has multiple benefits independent of fraud proofs or adopting a new "security model". Of course one is increasing the effective block size. Another is malleability as you mentioned. Another is being able to not download signatures when you aren't going to verify them, reducing bandwidth and improving sync time (full nodes already don't verify signatures below checkpoints, but they still have to download them). The latter two are mentioned in the rationale for SW in the Elements sidechain, where SW was first introduced (though not in this new soft-fork form, and not counting BBR of course). The last is the only benefit in BBR. The first two don't apply to any Cryptonote coin, and Maxwell knows this well since he is quite knowledgeable about Cryptonote.

That is not the issue Maxwell was referring to.

I never said it was, though since I don't know exactly what he meant I can't say either way for certain.

Even in my SW security model block chain design

Please try to stay on topic ("CryptoNote technical discussion") and avoid spamming mentions of your own coin.

[TPTB_need_war]

It sounds like we've gotten to the point of guessing what he meant, which is probably not too useful. Unless we can identify some specific serious vulnerabilities.

The serious vulnerability exists if someone has implemented SW security model, because then no one can proof that a transaction was invalidly signed for. This is the inversion of the property of proving that all the signatures are valid. You can proof it was validly signed for, but not invalidly signed for. So that is the only possibility of what Maxwell could have meant. Thus we are not guessing what he meant. Reading that linked Reddit thread, he was clearly unaware that BBR had implemented SW, thus he took the word of peanutbuttercoin literally and said that if you have SW security model without hashes of the signatures, then you have serious vulnerability in your security model. But this does not apply to BBR, because BBR never implemented a SW security model.

Nobody said that it implemented fraud proofs (which is what these proofs of invalidity are being called in bitcoin development). So maybe he assumed that, if so then incorrectly.

Go read that thread again. Maxwell was clearly assuming that peanutbuttercoin was insinuating that BBR had implemented SW. Clearly Maxwell wasn't aware of what "boolberry" had done and he was reacting to peanutbuttercoin's statement that BBR had not implemented hashes of signatures in its SW implementation. There is no other possible explanation that makes any sense. Even the thread reads clearly that Maxwell was responding the what peanutbuttercoin asserted was the case.

I personally don't care. I was trying to help those who asked for some clarification and even was using my scarce free time to try to help you as well. They call this sharing. As in the open source spirit. I thought I was being a good, helpful participant.

Even in my SW security model block chain design

Please try to stay on topic ("CryptoNote technical discussion") and avoid spamming mentions of your own coin.

I was agreeing with your point that not storing hash is silly. I mispelled "prove" as "proof" twice so obviously I wasn't putting a lot of effort into every pedantic detail. I didn't even consciously contemplate that I was doing something that would touch your nerve.

I heard Vaseline works well, but I haven't tried it myself.

Good grief, can't we just have a discussion without turning it into nonsense fights. Most of the verbiage was focused on the main point which was to address the concerns and details pertaining to that issue or recently to anonymity in general. As for competition, the few words we say here don't mean shit. It is all the hours of coding and all the effort put into marketing that will. If you think this thread is relevant in the marketing context, you've got larger hurdles than I even presumed.

You still don't have a clue that I don't need any promotion in this forum. I could have already launched my coin and you wouldn't even know. I have much bigger challenges (problems to meet head on) and bigger fish to fry (or crash and burn if I fail), than this. We were just having a discussion in Altcoin discussion which is a no man's land if considered relative to global scale of marketing.

I've got much bigger problems and issues to deal with pertaining to marketing success or failure. My reason for participating here is to help myself, you and others on brainstorming issues. It is totally out-of-proportion to worry about a slip of a few words here or there.

I would have been probably best served by saying nothing about RingCT and CN anonymity probably being a  dead-end compared to Zerocash. This is only a recently realization for me and I am not yet 100% final on that insight. But how does it help me in a competitive sense to get you, Shen, Blockstream, and the rest of Monero to stop wasting effort and refocus your efforts in another direction. If I was being selfish, I should STFU and let you go on without sharing my brainstorming.

[LucyLovesCrypto]

In our game I vote for 37.Rd1

What is our rook doing on b2? If 37.Rd2 a5 we can play 38.Rb2 again opening up some queenside files. If that does not happen our f1 rook seems better placed than our b2 rook. I like the idea of pressuring d6 to keep black on the defensive.

37.Rd1: XMRpromotions
37.Rd2: LucyLovesCrypto

[smooth]

You still don't have a clue that I don't need any promotion in this forum.

Good, then please try to stay on topic which is chess and cryptonote, and avoid dropping in additional mentions to your own coin, as you just did. Thanks.

[ArticMine]

In our game I vote for 37.Rd1

What is our rook doing on b2? If 37.Rd2 a5 we can play 38.Rb2 again opening up some queenside files. If that does not happen our f1 rook seems better placed than our b2 rook. I like the idea of pressuring d6 to keep black on the defensive.

37.Rd1: XMRpromotions
37.Rd2: LucyLovesCrypto

It also leaves us with weaknesses on a4 and c4 after ...a5 38. Rb2 ab4 39 Rb4. So I vote for 37. Rd1

[boolberry]

In our game I vote for 37.Rd1

What is our rook doing on b2? If 37.Rd2 a5 we can play 38.Rb2 again opening up some queenside files. If that does not happen our f1 rook seems better placed than our b2 rook. I like the idea of pressuring d6 to keep black on the defensive.

37.Rd1: XMRpromotions
37.Rd2: LucyLovesCrypto

It also leaves us with weaknesses on a4 and c4 after ...a5 38. Rb2 ab4 39 Rb4. So I vote for 37. Rd1

Current position
Based on the votes in this thread Team Monero has chosen to play Rd1. Now it is time for Team Boolberry to respond. I will plan to count votes again tomorrow at approximately 0:00 UTC.

Team Monero (white pieces) vs. Team Boolberry (black pieces)
black to move


Game PGN:

Code:

1.e4 c5 2.Nf3 d6 3.d4 cxd4 4.Qxd4 a6 5.c4 Nc6 6.Qe3 g6 7.Nc3 Bg7 8.Be2 Nf6 9.O-O O-O 10.h3 Nd7 11.b3 Nc5 12.Bb2 f5 13.exf5 Bxf5 14.Rad1 Qa5 15.Rd2 Rf6 16.Nd5 Re6 17.Qf4 Ne4 18.Bxg7 Kxg7 19.Rb2 Nc3 20.Nd4 Re5 21.Bf3 Nxd5 22.Bxd5 Qc3 23.Nxf5+ Rxf5 24.Qd2 Qxd2 25.Rxd2 Rb8 26.a3 e5 27.Be6 Rf6 28.Bd5 Nd4 29.b4 b6 30.Rb2 g5 31.a4 Rff8 32.Rfb1 Rfc8 33.f3 Kf6 34.g3 Rc7 35.Rf1 Nf5 36.Kf2 h5 37.Rd1

[languagehasmeaning]

I like Rg7 to better prepare h4

1 vote Rg7: languagehasmeaning

[newb4now]

I like Rg7 to better prepare h4

1 vote Rg7: languagehasmeaning

2 votes Rg7: languagehasmeaning, newb4now

[boolberry]

3 votes Rg7: languagehasmeaning, newb4now, boolberry

[boolberry]

Current position
Based on the votes in this thread Team Boolberry has chosen to play Rg7. Now it is time for Team Monero to respond. I will plan to count votes again tomorrow at approximately 0:00 UTC.

Team Monero (white pieces) vs. Team Boolberry (black pieces)
white to move


Game PGN:

Code:

1.e4 c5 2.Nf3 d6 3.d4 cxd4 4.Qxd4 a6 5.c4 Nc6 6.Qe3 g6 7.Nc3 Bg7 8.Be2 Nf6 9.O-O O-O 10.h3 Nd7 11.b3 Nc5 12.Bb2 f5 13.exf5 Bxf5 14.Rad1 Qa5 15.Rd2 Rf6 16.Nd5 Re6 17.Qf4 Ne4 18.Bxg7 Kxg7 19.Rb2 Nc3 20.Nd4 Re5 21.Bf3 Nxd5 22.Bxd5 Qc3 23.Nxf5+ Rxf5 24.Qd2 Qxd2 25.Rxd2 Rb8 26.a3 e5 27.Be6 Rf6 28.Bd5 Nd4 29.b4 b6 30.Rb2 g5 31.a4 Rff8 32.Rfb1 Rfc8 33.f3 Kf6 34.g3 Rc7 35.Rf1 Nf5 36.Kf2 h5 37.Rd1 Rg7

[LucyLovesCrypto]

Be4: LucyLovesCrypto