Pages:
Author

Topic: delete - page 47. (Read 165547 times)

legendary
Activity: 2968
Merit: 1198
October 03, 2014, 07:21:32 PM
If the XMR code wasn't a shitload of C and written in some higher-level language such as Scala, I would enjoy coding it. Sorry I don't use C any more except for the optimized smallish portion of a code base. I wrote 10s of 1000s of lines of assembly and C code in the 1980s. Enough of that.
And thus I also like to code in high-level paradigms.

1. There is exceedingly little C except the crypto libraries (essentially copied from another existing crypto library project), which we aren't working on because existing crypto libraries are fine (other than verifying that the code has not been tampered with and tracks upstream fixes if any).  The bulk of the project is C++

2. Simulations, prototypes or other contributions can be in any language. Tacotime's simulation used Python. Prototypes have also been doing in Python and then converted to C++. Other work has been done with Matlab, and probably some others I don't remember. Scala or well-presented math or anything else is welcome and useful. Vague assertions of uncertainty and doubt are close to the definition of FUD. No one is trying to suppress that even (futile in practice to even try anyway), but I am pointing out that it isn't useful to Monero any other project.





legendary
Activity: 2968
Merit: 1198
October 03, 2014, 07:14:36 PM
I am 80% certain that this cultural stance is going to be why XMR is beaten by another effort that understands better how to spur innovation by not suppressing or expecting a Cathedral style of progression.

The cultural stance is not significantly distinguished from the range of cultures I've seen on other open source projects on which and with which I've worked, which is quite a few.

Your characterization of it as a cathedral is straw man.

Perhaps it is a cathedral compared to your internal mental model of what constitutes bazzaar-style development, but by the standards of reality it is not.

Quote
You are equating the ability for a user to wait for say 6 confirmations to have a mathematically quantifiable probability of assurance, with the risk of a coin vulnerability allowing spends of any age to be double-spent (reverting a spend is double-spending).

No, I'm saying that any recipient of any coin is vulnerable to a chain fork that removes the transaction they received. This is mitigated by a judgement of the recipient that they have waited "long enough" for such a chain fork to become unlikely. I said nothing about 6 confirms. In practice recipients make their own judgement about number of confirms. In Bitcoin many use less, and in altcoins many require far more. In all cases there is likely some sort implicit or explicit fraud scoring, but that is really none of my business and is up to the recipients to sort out. Ring signatures do nothing to change this except what they are intended to do (inhibit tracing, and thus indirectly blacklisting), and nothing here is remotely specific to Monero.

Quote
Thus he is factually stating any relevance to BCX is unproven and not obvious. He is not saying there is no possible relevance, although I am assuming he thinks the probability is exceedingly small thus the onus on someone other than them to prove it is relevant.

Not exactly.I'm saying that useful contributions take the form of actual math or code. "There might be a flaw" is FUD almost by definition.
newbie
Activity: 42
Merit: 0
October 03, 2014, 07:01:54 PM
so there paying u to find flaws and ur just badmouthing them and saying tehy don't care?

No that is a mischaracterization. What happened was that a bounty was offered for revealing an exploit that was shown to be stronger than what we had already published. The exploit turned out to have no obvious relevance to BCX, but nevertheless the requirements were met and the bounty was paid.

Agreed, except "a bounty" was paid and so far not "the bounty". Or at least last time I checked only 7.5 of 10 had been paid. Note smooth's group and jl777 paid instantly. It was explained to me that we have Christian leader who doesn't follow the Biblical instruction to pay wages daily upon agreed completion of work. A rich man floating on a poorer man's income is a sin according to the Bible. I used to do payables net 30 etc, until I became of aware of this Biblical verse and it shamed me.

The exploit turned out to have no obvious relevance to BCX...

Smooth is referring to the fact that I have not shown any proof that the private keys can be cracked, I only pointed to some simultaneous equations that are revealed when the spender of the ring is revealed per my (or their published) algorithm. One case of the simultaneous equations has been shown by their mathematicians to be equivalent to Diffie-Hellman exchange thus proven to be uncrackable by current assumptions. However, not all of the cases were disproven. Thus he is factually stating any relevance to BCX is unproven and not obvious. He is not saying there is no possible relevance, although I am assuming he thinks the probability is exceedingly small thus the onus on someone other than them to prove it is relevant.

Note afaics the mathematical point of Taleb's Antifragility is that many improbable long tail events accumulate.

Yet I think the algorithm they paid a bounty for may have an obvious relevance to BCX. If a BCX chain attack gets hopelessly wound in a Gordian knot, my algorithm may be able in some cases to untangle the anonymity so that it can be determined which transactions actually spent the stolen coin base rewards. I don't know how realistic it is until it is coded, tested, and characterized.

Useful contributions would likely take the form of code or well formed mathematical analysis. That is exceedingly rare here, but it does happen.

In case the issue of Linux comes up again, I will point out that I have personally made contributions to Linux. They took the form of recommended code changes coupled with test cases that clearly and explicitly demonstrated the benefit of the proposed code changes. If I simply posted about how this or that was a possible flaw without doing the work to support my claims, I would likely be ignored or ridiculed, as I have seen happen to many people in the Linux developer community.

Agreed. But you are conflating apples (Linux) and quarks (crypto-currency) because Linux is an effort to copy an existing operating system (Unix) and concept which was already fleshed out in the real world. Whereas, crypto-currency is still very much in the formative, research, experimentative, conceptual stage.

I am 80% certain that this cultural stance is going to be why XMR is beaten by another effort that understands better how to spur innovation by not suppressing or expecting a Cathedral style of progression.

TFM: "Entanglement" is no more an issue than reversal of the often-untraceable transfer of coins after a long (but ultimately temporary) chain fork, particularly through exchanges and other intermediaries. In both cases, when the fork is resolved one way or another, some transactions will be unwound, and those who accepted coins as valid on the wrong fork without a sufficient number of confirmations (always a judgement call) are out of luck.

Shocking.  Shocked

You are equating the ability for a user to wait for say 6 confirmations to have a mathematically quantifiable probability of assurance, with the risk of a coin vulnerability allowing spends of any age to be double-spent (reverting a spend is double-spending).
legendary
Activity: 1624
Merit: 1008
October 03, 2014, 06:57:03 PM
hero member
Activity: 835
Merit: 1000
There is NO Freedom without Privacy
October 03, 2014, 06:19:17 PM
My vocal opposition is due to your shills

Then it is based on a false premise, since we have never employed any shills.

Given the foundation of your position being false, you might want to reconsider it, at least if you are going to be honest and logically consistent about it at all. Obviously you are not forced to.

You don't have to employ shills to have shills

Actually we do, if you know what the word means. Shills are people who act without disclosing their affiliation. If they had some affiliation, they would be shills, but they don't so they are not. They are just supporters (with whom you can certainly disagree) or possibly shills for someone else doing a reverse psychology attack. (Third possibility being detractors who are not shills doing a reverse psychology attack.)


newbie
Activity: 42
Merit: 0
October 03, 2014, 06:16:12 PM
One person's FUD is another person's eureka instigator.

I'm waiting for that to happen even once. Then I will be convinced.

Some Bitcoin devs thought selfish mining was FUD.

I understand you want BCX to walk them through an attack with more details, but you know even most very smart Bitcoin devs didn't think selfish mining was real after the white paper was published until they went and built simulations to disprove it and ended up proving it.


In this space the reasonable a priori belief is that FUD is just FUD.

That does not mean it can't be reevaluated in light of new evidence, but without evidence, no, and without reevaluation the a priori remains rationally useful.

Irrational.

FUD (fear, uncertainty, doubt) is the reality because you don't know how vulnerable XMR is or is not. Thus it is healthy and should be priced in. Controlling information flow to prevent credible FUD dissemination is very unhealthy and prevents Antifragility. Note I am distinguishing credible and rational discussion of concepts from pure chicken little noise from n00bs.

http://unheresy.com/Information%20Is%20Alive.html#Knowledge_Anneals

The code is open to all eyeballs, just as is Linux. Github, including developer's forks on github are open. Discussions on #monero-dev and other suitable channels are also open.

There is nothing being hidden, but we await actionable competently analyzed information. So far there has been none.

If the XMR code wasn't a shitload of C and written in some higher-level language such as Scala, I would enjoy coding it. Sorry I don't use C any more except for the optimized smallish portion of a code base. I wrote 10s of 1000s of lines of assembly and C code in the 1980s. Enough of that.



I sat on the developer IRC for a while and I see mostly talk about the nitty gritty details about the source code. Sorry I am a high-level thinker. And thus I also like to code in high-level paradigms.
member
Activity: 112
Merit: 10
October 03, 2014, 06:06:38 PM
gotit - my bad
legendary
Activity: 2968
Merit: 1198
October 03, 2014, 05:54:04 PM
so there paying u to find flaws and ur just badmouthing them and saying tehy don't care?

No that is a mischaracterization. What happened was that a bounty was offered for revealing an exploit that was shown to be stronger than what we had already published. The exploit turned out to have no obvious relevance to BCX, but nevertheless the requirements were met and the bounty was paid.

TFM is not "working for" the Monero project and has no obligation to us at all. He is welcome to contribute based on the project being open source as I discussed in my previous message. Useful contributions would likely take the form of code or well formed mathematical analysis. That is exceedingly rare here, but it does happen.

In case the issue of Linux comes up again, I will point out that I have personally made contributions to Linux. They took the form of recommended code changes coupled with test cases that clearly and explicitly demonstrated the benefit of the proposed code changes. If I simply posted about how this or that was a possible flaw without doing the work to support my claims, I would likely be ignored or ridiculed, as I have seen happen to many people in the Linux developer community.

TFM: "Entanglement" is no more an issue than reversal of the often-untraceable transfer of coins after a long (but ultimately temporary) chain fork, particularly through exchanges and other intermediaries. In both cases, when the fork is resolved one way or another, some transactions will be unwound, and those who accepted coins as valid on the wrong fork without a sufficient number of confirmations (always a judgement call) are out of luck. The only possible difference would be the ability to blacklist "bad" coins in traceable chains but not Monero, and this is a feature not a bug.


newbie
Activity: 42
Merit: 0
October 03, 2014, 05:50:19 PM
bite the hand that feeds u much?

Expending my scarce time to for example explain why checkpoints are not a complete solution is not helping?

That some people think I am not helping means they are biting the hand that feeds them.

So you agree ring signature entanglement from the coinbase transactions of the attackers fork could in theory occur??

How to unwind those?
This is a good question.
I'd like to think about it a bit, but I am still cleaning up the NEFT that spurted out of my face a while back.
After that, I'm going to feed the alpacas and see if anything comes to me.
It is a really good question.  Just too many distractions at the moment.

member
Activity: 112
Merit: 10
October 03, 2014, 05:48:34 PM
Quote
Refer to the upthread exchange with fluffypony wherein he stated that until an attack was demonstrated, they could assume they could unwind any damage from a future attack, and that he had time to go think at the beach with his wife (the implication was that I was too stressful and paranoid).

Quote
And XMR paid me (7.5 BTC thus far, 2.5 BTC in arrears) to supplement that with a potential amplification and mitigation

so there paying u to find flaws and ur just badmouthing them and saying tehy don't care?

bite the hand that feeds u much?
legendary
Activity: 2968
Merit: 1198
October 03, 2014, 05:45:21 PM
You lost the argument. Your coin is driven by shills - paid or unpaid - makes no difference.

Most certainly. Congratulations on your successful triumph by the unassailable power of proof by assertion.

Oh wait, was there some other evidence of shills that I missed?

 
legendary
Activity: 2968
Merit: 1198
October 03, 2014, 05:44:11 PM
One person's FUD is another person's eureka instigator.

I'm waiting for that to happen even once. Then I will be convinced.

In this space the reasonable a priori belief is that FUD is just FUD. That does not mean it can't be reevaluated in light of new evidence, but without evidence, no, and without reevaluation the a priori remains rationally useful.

The code is open to all eyeballs, just as is Linux. Github, including developer's forks on github are open. Discussions on #monero-dev and other suitable channels are also open.

There is nothing being hidden, but we await actionable competently analyzed information. So far there has been none.



legendary
Activity: 1638
Merit: 1001
October 03, 2014, 05:39:17 PM
"Accomplice" implies active participation or working in concert. There no one actively participating in the project or working with us, or contributing who pretends not to be. Everyone affiliated with the project is open about it. Anyone else is not affiliated.

Here is a definition that is clearer, from wikipedia:

"A shill, also called a plant or a stooge, is a person who publicly helps a person or organization without disclosing that they have a close relationship with the person or organization"

My time on planet earth is more valuable than this.

You lost the argument. Your coin is driven by shills - paid or unpaid - makes no difference.

Have fun counterarguing this point with an empty chair.

Monkeydiaperchanger, an empty chair symbolizes your relevance succinctly and completely.
newbie
Activity: 42
Merit: 0
October 03, 2014, 05:38:19 PM
-blah-

Jimbob...you read our Monero Research Lab's very first publication, right? You know the one where we spoke about a cascading privacy failure if an attacker owned sufficient outputs? Here's a link for you to save yourself. At any rate, this could occur in a CryptoNote coin where persons unknown to everyone else controlled, to thumb suck an example, 82% of all the outputs. That would be an exceedingly unsafe CryptoNote coin to use, as those person(s) could easily reveal the actual signature of just about any transaction, thus negating any benefit of ring signatures.

When choose a currency to shill for, you really should choose one that doesn't have that flaw.

And XMR paid me (7.5 BTC thus far, 2.5 BTC in arrears) to supplement that with a potential amplification and mitigation, where for example in some cases the attacker doesn't even need any of the outputs that are in the ring signature. Omitting my contribution (which y'all paid for, thank you) could possibly be construed as subconscious "not invented here bias" (hope not).

The extent of that vulnerability has not been quantified and thus nothing of substance is demonstated, we merely have a proof of concept and a supposition. By contrast, the MRL-0001 analysis that shows numerically that 82% control with low typical mixin usage on the network is clearly devastating.

FUD (aka repeatedly proclaiming "this might be a flaw/vulnerability" ) is easy. Proving something to be an actual practical vulnerability is much harder.

Agreed.

That is certainly not "not invented here." We've uncovered various potential issues that are also in need of in depth analysis. We consider both to be in the same category, ...

Commendable.

... except that we don't go around shouting about "possible flaw" before we actually know the validity and extent we are looking it.

Controlled information is never as efficient as an Inverse Commons. The reason is Linus's law, "given enough eyeballs, every bug is shallow".

One person's FUD is another person's eureka instigator.

Myself and others have many times tried to suggest that the culture of controlling information flow is what is causing such a big problem for XMR's public perception. I also have this private speculation (my pet theory) that it limits the technical innovation, diluting the impressive brain power in the group.

Information and truth want to be free(dom).
legendary
Activity: 3010
Merit: 8114
October 03, 2014, 05:34:59 PM
"Accomplice" implies active participation or working in concert. There no one actively participating in the project or working with us, or contributing who pretends not to be. Everyone affiliated with the project is open about it. Anyone else is not affiliated.

Here is a definition that is clearer, from wikipedia:

"A shill, also called a plant or a stooge, is a person who publicly helps a person or organization without disclosing that they have a close relationship with the person or organization"

My time on planet earth is more valuable than this.

You lost the argument. Your coin is driven by shills - paid or unpaid - makes no difference.

Have fun counterarguing this point with an empty chair.
newbie
Activity: 42
Merit: 0
October 03, 2014, 05:28:37 PM
legendary
Activity: 2968
Merit: 1198
October 03, 2014, 05:23:24 PM
-blah-

Jimbob...you read our Monero Research Lab's very first publication, right? You know the one where we spoke about a cascading privacy failure if an attacker owned sufficient outputs? Here's a link for you to save yourself. At any rate, this could occur in a CryptoNote coin where persons unknown to everyone else controlled, to thumb suck an example, 82% of all the outputs. That would be an exceedingly unsafe CryptoNote coin to use, as those person(s) could easily reveal the actual signature of just about any transaction, thus negating any benefit of ring signatures.

When choose a currency to shill for, you really should choose one that doesn't have that flaw.

And XMR paid me (7.5 BTC thus far, 2.5 BTC in arrears) to supplement that with a potential amplification and mitigation, where for example in some cases the attacker doesn't even need any of the outputs that are in the ring signature. Omitting my contribution (which y'all paid for, thank you) could possibly be construed as subconscious "not invented here bias" (hope not).

The extent of that vulnerability has not been quantified and thus nothing of substance is demonstated, we merely have a proof of concept and a supposition. By contrast, the MRL-0001 analysis that shows numerically that 82% control with low typical mixin usage on the network is clearly devastating.

FUD (aka repeatedly proclaiming "this might be a flaw/vulnerability" ) is easy. Proving something to be an actual practical vulnerability is much harder.

That is certainly not "not invented here." We've uncovered various potential issues that are also in need of in depth analysis. We consider both to be in the same category, except that we don't go around shouting about "possible flaw" before we actually know the validity and extent we are looking it.


newbie
Activity: 42
Merit: 0
October 03, 2014, 05:21:31 PM
-blah-

Jimbob...you read our Monero Research Lab's very first publication, right? You know the one where we spoke about a cascading privacy failure if an attacker owned sufficient outputs? Here's a link for you to save yourself. At any rate, this could occur in a CryptoNote coin where persons unknown to everyone else controlled, to thumb suck an example, 82% of all the outputs. That would be an exceedingly unsafe CryptoNote coin to use, as those person(s) could easily reveal the actual signature of just about any transaction, thus negating any benefit of ring signatures.

When choose a currency to shill for, you really should choose one that doesn't have that flaw.

And XMR paid me (7.5 BTC thus far, 2.5 BTC in arrears) for a supplement to that which is an idea for potential amplification and mitigation, where for example in some cases the attacker doesn't even need any of the outputs that are in the ring signature. Omitting my contribution (which y'all paid for, thank you) could possibly be construed as subconscious "not invented here bias" (hope not).
hero member
Activity: 544
Merit: 500
October 03, 2014, 05:21:23 PM

So you're claiming that Moneroman88 is Bluemenie?

No, Moneroman claimed he is BlueMeanie.

I am not BM.



You got busted!!
sr. member
Activity: 497
Merit: 251
October 03, 2014, 05:20:31 PM
too much drama, way too much drama.
more development needed not blabla! smooths et al. post history is 99% drama recently. We want to see advancement guys! Don't let this shitstorm get you down and continue developing please, or have you stopped?
Pages:
Jump to: