Gold collapsing. Bitcoin UP.

[justusranvier]

Everyone and his brother has had the idea of hitching a highly subsidized ride on the blockchain for messenging, time-stamping, secure data storage, etc.  The 1MB setting has been the downfall of each.  Without it it is highly unlikely that the system would look like what we have today (and what I like very much.)  If/when the 1MB thing goes away there are a lot of these 'bad' ideas waiting in the wings to capitalize on the mistake.

As long as people pay for what people use, who are you to say what they should or should not put in the blockchain?

I suspect one reason I see so much resistance to the idea of fixing the network so that people do pay for what they use is precisely because then the people who want to dictate how Bitcoin can and can not be used suddenly will be unable to justify their position.

[tvbcof]

Everyone and his brother has had the idea of hitching a highly subsidized ride on the blockchain for messenging, time-stamping, secure data storage, etc.  The 1MB setting has been the downfall of each.  Without it it is highly unlikely that the system would look like what we have today (and what I like very much.)  If/when the 1MB thing goes away there are a lot of these 'bad' ideas waiting in the wings to capitalize on the mistake.

As long as people pay for what people use, who are you to say what they should or should not put in the blockchain?

Typical horseshit dipped in free-market chocolate and tuned chant from one of the masters.  In case it escaped you, large entities will happily give you a reach-around if you allow them to fuck you in the ass.  That distorts any campy 'free-market' dynamics completely beyond recognition.

I suspect one reason I see so much resistance to the idea of fixing the network so that people do pay for what they use is precisely because then the people who want to dictate how Bitcoin can and can not be used suddenly will be unable to justify their position.

All systems are designed with constraints which define how they will exist in the real world.  The constraints on utilization rate in Bitcoin has a DIRECT bearing on how the support infrastructure evolves.  I (pretty much alone as far as I can tell) rate the utilization rate to be a more important design feature than the inflationary parameters.  This because I rate defensibly so highly as the value proposition of a distributed crypto-currency.

Because of the fairly impressive and technical work of the Blockstream guys on their sidechains stuff, sidechains can likely become a nearly perfect proxy for BTC itself and do so without straining the native utilization rate configuration which keeps it potentially secure.  Coupled with the ability to custom tune solutions to particular niches, this is a significantly more ideal outcome than simply growing the native system even if that were safe to do.

[justusranvier]

Typical horseshit dipped in free-market chocolate and tuned chant from one of the masters.  In case it escaped you, large entities will happily give you a reach-around if you allow them to fuck you in the ass.  That distorts any campy 'free-market' dynamics completely beyond recognition.

Great argument,

[TPTB_need_war]

Because I am not up-to-speed on communicating with the Monero devs (on Github or other back channels), and because my efficiency is my utmost priority and given posting in this forum is the most efficient way for me to communicate my thoughts to all that follow me, I will post this somewhat out-of-band comment here in hopes of getting a response from smooth (or if need be tacotime or fluffypony).

I do not have time to read various Monero research papers and otherwise dig to see if the following concern is already addressed.

I am concerned about a hole in the anonymity of Cryptonote ring signatures. I had sort of described this issue to smooth (who apparently relayed it to all) when I was contemplating ways that BCX might unmask the anonymity of users. I do not recall if I made this specific weakness explicit as follows.

If the actual input to a transaction (in Monero terminology this is the output of the prior transaction) is not also an input to another transaction's ring signature (and when all the other inputs to the ring are spent) or if it is also the input to a subsequent ring in which all the other inputs were outputs created after the said transaction was created, then the anonymity of the said transaction is entirely unmasked.

Combinatorial trees can be searched as well, thus even if only some of the other inputs were outputs created after the said input was created, this could cascade into unmasking the anonymity or at least reducing the anonymity set. And note the anonymity set also vulnerable to further reduction by out-of-band attacks such as IP de-obfuscation, rubber hoses, stolen private keys, hacked users, etc.

There are some tweaks that need to be made to insure the above is unlikely. Hopefully Monero is enforcing some restrictions already on which outputs can be used in ring inputs? If not, they need to get on it pronto.

P.S. for those who thought I wasn't sincerely attempting to help Monero during the BCX incident, I hope the above satisfies you. I think before I had an agreement with the Monero devs (via smooth) not to write publicly all the details of the above weakness in order to give them time to address it. I think they've had sufficient time and I want to make sure this is addressed.

[fluffypony]

If the actual input to a transaction (in Monero terminology this is the output of the prior transaction) is not also an input to another transaction's ring signature (and when all the other inputs to the ring are spent) or if it is also the input to a subsequent ring in which all the other inputs were outputs created after the said transaction was created, then the anonymity of the said transaction is entirely unmasked.

This is really what MRL-0004 deals with (the section on Temporal Association attacks).

A lot of this changes with the recommendations MRL4 made, which will come in a hard fork later this year (once we've established a forking strategy, per this forum post).

I don't check this thread, so if you reply and don't hear back from me in a couple of days just send me a PM nudging me:)

[majamalu]

In case it escaped you, large entities will happily give you a reach-around if you allow them to fuck you in the ass.

You mean I should be afraid that Mcdonald's may send a hitman instead of a cheeseburger?

[macsga]

In case it escaped you, large entities will happily give you a reach-around if you allow them to fuck you in the ass.

You mean I should be afraid that Mcdonald's may send a hitmen instead of a cheeseburger?

Cheeseburger IS, in essence, a hitman (it will only kill you slowly)...

[majamalu]

In case it escaped you, large entities will happily give you a reach-around if you allow them to fuck you in the ass.

You mean I should be afraid that Mcdonald's may send a hitman instead of a cheeseburger?

Cheeseburger IS, in essence, a hitman (it will only kill you slowly)...

As Voltaire said when he was informed by his physician that coffee was a “slow, steady poison”: “Yes, it must be a slow poison, it has been poisoning me for over seventy years!”   

[TPTB_need_war]

If the actual input to a transaction (in Monero terminology this is the output of the prior transaction) is not also an input to another transaction's ring signature (and when all the other inputs to the ring are spent) or if it is also the input to a subsequent ring in which all the other inputs were outputs created after the said transaction was created, then the anonymity of the said transaction is entirely unmasked.

This is really what MRL-0004 deals with (the section on Temporal Association attacks).

A lot of this changes with the recommendations MRL4 made, which will come in a hard fork later this year (once we've established a forking strategy, per this forum post).

I don't check this thread, so if you reply and don't hear back from me in a couple of days just send me a PM nudging me:)

The MRL4 imperfect heuristic mitigations notwithstanding, the only absolute solution is to require that sets of outputs be mixed with and only with each other (and the number of inputs per ring must be constant). This also enables pruning the Cryptonote block chain. There I have just given away one of my prior design "secrets" (that I no longer need to keep secret because I stumbled onto a consensus network design which no longer needs pruning and is transaction technology agnostic). Perhaps others already suggested this?

P.S. for those who have already spent their coins to a third party, your hard fork will come too late. Hope you can make necessary improvements sooner.

[solex]

Changing the supply limit fundamentally destroys bitcoin, but increasing the blocksize limit is absolutely needed to make it successful.

Thanks for the distilled wisdom!

I have updated my sig.

[TPTB_need_war]

Changing the supply limit fundamentally destroys bitcoin, but increasing the blocksize limit is absolutely needed to make it successful.

Oh the strawmen strive for a world with only two opposing choices.

[solex]

Changing the supply limit fundamentally destroys bitcoin, but increasing the blocksize limit is absolutely needed to make it successful.

Oh the strawmen strive for a world with only two opposing choices.

The perfect is the enemy of the good

[TPTB_need_war]

One of the reasons I think it's important to be cautious here is so that we can have CT (or a superior successor technology) in the Bitcoin network and not just in a sidechain.

And when the 50% attack has been rendered impossible by some new design, then it no longer becomes necessary to retrofit the Core Bitcoin network. That will radically alter the impact of what you are about to unleash.

[TPTB_need_war]

But to reach 100k tps will still be tough regardless of implementation.

My design has no theoretical limit on TPS. It will be published this year and I hope within a couple of months.

There always is bottleneck as long as there is physics

My consensus network PoW design places no theoretical limit on the TPS. Physics will still place a limit else where (i.e. aggregate bandwidth of the entire internet), but that limit won't be at the layer of the consensus network. In short, I don't see any practical limit yet, but I caution there has been no peer review. And I've been pretty much overloaded while making this discovery, so it is possible I've overlooked a flaw. I don't think so. The one flaw I'm contemplating is how to set the minimum transaction fees to avoid a Sybil attack while retaining decentralization of that adjustment. But Bitcoin has the analogous dilemma in that if block size is unlimited then attacks are possible (unless also set a minimum transaction fee) and these constants are not set with a decentralized process. So at least my design seems to have the potential of a great leap forward, even if the Holy Grail of decentralization will never quite be entirely devoid of politics.

[marcus_of_augustus]

It's possible that the covert power grab of the manufactured "governance crisis" by gavin and the MIT g-men may have unintended consequences of their own. (I never took gavin for a blockhead or a hot-head, as he has come across in this debate, but now it is clear there are ulterior motives that fit the observed behaviour much better. Now he just seems like a regular, Machiavellian, conniving politician, it's like he has been media-coached by Hearn.)

Red-team blue-team politics is cat-nip for attracting and fostering interest. We even have referee Garzik to keep the fight clean.

Go at it guys but careful you don't kill the goose that lays the golden eggs.

[macsga]

It's possible that the covert power grab of the manufactured "governance crisis" by gavin and the MIT g-men may have unintended consequences of their own. (I never took gavin for a blockhead or a hot-head, as he has come across in this debate, but now it is clear there are ulterior motives that fit the observed behaviour much better. Now he just seems like a regular, Machiavellian, conniving politician, it's like he has been media-coached by Hearn.)

Red-team blue-team politics is cat-nip for attracting and fostering interest. We even have referee Garzik to keep the fight clean.

Go at it guys but careful you don't kill the goose that lays the golden eggs.

Maybe that's what they were after involving Gavin in this game after all. Or maybe we're chasing ghosts here, for that matter. Only time will tell.

[TPTB_need_war]

If the actual input to a transaction (in Monero terminology this is the output of the prior transaction) is not also an input to another transaction's ring signature (and when all the other inputs to the ring are spent) or if it is also the input to a subsequent ring in which all the other inputs were outputs created after the said transaction was created, then the anonymity of the said transaction is entirely unmasked.

This is really what MRL-0004 deals with (the section on Temporal Association attacks).

A lot of this changes with the recommendations MRL4 made, which will come in a hard fork later this year (once we've established a forking strategy, per this forum post).

I don't check this thread, so if you reply and don't hear back from me in a couple of days just send me a PM nudging me:)

The MRL4 imperfect heuristic mitigations notwithstanding, the only absolute solution is to require that sets of outputs be mixed with and only with each other (and the number of inputs per ring must be constant). This also enables pruning the Cryptonote block chain. There I have just given away one of my prior design "secrets" (that I no longer need to keep secret because I stumbled onto a consensus network design which no longer needs pruning and is transaction technology agnostic). Perhaps others already suggested this?

P.S. for those who have already spent their coins to a third party, your hard fork will come too late. Hope you can make necessary improvements sooner.

The following should have been implied, but let me make it more explicit, which may also resolve the issue with exchanges and getting this fix into Monero asap (although I have not studied that issue, only heard about it second hand).

The only sane way my above suggestion can be implemented is that outputs eligible for fixed size mixins must be marked as such by the transaction that created them, otherwise if the fixed size (and outputs) mixins were global then there is no way to merge the leftover change from several transactions into one transaction. I believe BoolBerry had a conceptually similar mechanism to mark outputs with some specific attribute for mixing. So the marked outputs must be mixed with and only with the "next N outputs of same denomination on the block chain" when they are spent.

Thus when you want to mix your outputs with assurance against unmasking due to Combinatorial Cascade and Temporal Association, then you mark the output for fixed size mixing.

In my opinion, this is an emergency fix because afaics the anonymity is broken as it is now, but I can't say that I've done any deep analysis on how likely the unmasking is on existing patterns in the Monero block chain.

Hope this helps, displays my gratitude to those who rewarded me for my effort during the BCX incident, and most importantly hope Monero can implement it asap because I would like to make my best attempt to create a use case gift to XMR HODLers soon and this fix may be required. Perhaps someone else had already suggested this idea, I don't know.

The pruning comes from the fact that if the mixes are fixed size then after N transactions of the same ring have been seen, those outputs (that are inputs to those N rings) can be pruned from the UXTO.

[cypherdoc]

Nash:

http://www.coindesk.com/did-john-nash-help-invent-bitcoin/?utm_content=bufferc4078&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer

[tvbcof]

Suddenly today I am really sensing a sea-change as people wake up to what the Hearn and the bloat push is all about.

I'm just curious about whether the poll in this thread is configured to allow people to change their vote or not (cypherdoc?)

[greenlion]

It's possible that the covert power grab of the manufactured "governance crisis" by gavin and the MIT g-men may have unintended consequences of their own. (I never took gavin for a blockhead or a hot-head, as he has come across in this debate, but now it is clear there are ulterior motives that fit the observed behaviour much better. Now he just seems like a regular, Machiavellian, conniving politician, it's like he has been media-coached by Hearn.

The only concrete ulterior motives that I'm seeing is that Blockstream's profitability entirely depends on scoring consulting clients to support implementing the technologies that they're working on, whose necessity to implement quickly depend on the blocksize not increasing. But if the blocksize simply must be increased, Adam Back's ultra-complicated Rube Goldberg-esque extension block proposal is there to ensure that practically every enterprise in the space has massive incentive to employ Blockstream to have a smooth implementation.