Gold collapsing. Bitcoin UP.

[rocks]

I hate the fact that politics must be played.  But after this debacle, sidechains had better be more awesome than the second coming of Satoshi if they want to make mods that are so much more complicated than changing a constant that there is simply no comparative basis.
My guess is that they want to delay blocksize so they can cram sidechain mods into the same fork as a negotiated compromise.  But this is turning into a huge mistake.  They are burning all the goodwill they had, and making us suspect them of not wanting what's best for bitcoin.  This reputation is going to badly affect their ability to get consensus in the future.

The opposition to Gavin's 2000% jump proposal comes unanimously from every active technical contributor to Bitcoin Core who has spoken up. This should suggest to you that your understanding of the comparative basis likely miscalibrated.  Though there is no comparative basis, 2WP sidechains are something that just requires non-broken smart contracts, it's not something that needs a hard-fork (and the centralized fedpeg sidechain stuff is indistinguishable, uncensorable, and unblockable: you can't prevent people from using it no matter how much you think you should be able to tell them that they can manage their funds).

Considering how often cypherdoc brags about his thread here being filled with economic wisdom, it's surprising to see views like "changing a constant simple and safe", after all 21 million bitcoins is merely a constant (and, pedantically, one the system didn't originally enforce....).  Try another strawman.
 

MV = PT

A hard cap on the supply "M" was always the intent.
During my time spent immersed in Bitcoin never was the intent to limit Velocity or Transactions too be enforced by the Bitcoin protocol.

The idea of limiting Velocity or Transactions is a radical one, M is intentionally limited in the Bitcoin experiment, not V or T. Thinking it's OK to move Bitcoins V or T to a shidechain that is managed by the same incentives scheme that preserves the Bitcoin protocol is as radical as increasing "M" in the Bitcoin experiment.  

and to think there is no difference between "2WP sidechains are something that just requires non-broken smart contracts" in effect Sidechain Elements, a fantastic achievement by the way, and doing the same thing without a trust or a distributed server enforced by Bitcoin protocol to manipulate V or T  off the Bitcoin blockchain is an expression of macro economic ignorance.  

Well stated.

gmaxwell, trying to conflate the supply limit and blocksize limit as equivalent "constants" and thus implying that changing the blocksize is as impactful as changing the supply is absurd. Changing the supply limit fundamentally destroys bitcoin, but increasing the blocksize limit is absolutely needed to make it successful.

There are 2 basic economic truths that you, Peter, LukeJr, etc have misrepresented for the past several weeks IMHO.

1) To ensure there are enough long-term fees to support and protect Bitcoin after the inflation rate levels off, it is necessary to significantly increase  the blocksize and tps. More available transactions, in turn drives more usage of Bitcoin, increasing the overall value of the system. Additionally it is the minimum fee structure that will generate fees over many transactions, not supply pressure forcing higher fees over a small number of transactions as the blockstream devs have been promoting.

2) Significantly increased blocksizes in absolutely no manner reduces Bitcoin's decentralization. Bitcoin's decentralization is the mining security process which anyone can participate in. Miners work through pools and blocksize has no effect on them. We could go to 1TB blocks tomorrow and miners would not notice. At the same time pools are already centralized to the point that they can handle whatever blocksize is needed. There will still always be enough pools that if any misbehave, miners would leave the abuser in droves and switch to an honest pool.

The only reason Satoshi added the 1MB limit was to prevent a bad actor from quickly bloating the blockchain prior to SPV-type wallets. That was the only reason. Now that most people have SPV-type light wallets, the limit does not really matter. Those still running a full node can manage it.

Bitcoin is first and foremost an economic system, the basic crypto used in Bitcoin are just tools. The entire position you and the others have taken have demonstrated that either: a) you guys do not understand the economics behind Bitcoin and it's security mechanism or b) you do but Blockstream has completely corrupted your ability to view the situation properly. In either case I have found the arguments you and the others have used to be lacking and more to the point seem to intentionally confuse the issues here.

The most beautiful aspect of Bitcoin is it's voluntary consensus mechanism. This means there is no group of "experts" to dictate terms to any of us, and anyone can choose the branch of their own choosing. You can be sure I am following the branch and view of Bitcoin's future that aligns to wide scale usage, and from the voting patterns I've seen at reddit and elsewhere most others will as well.

[1695290629]

1695290629

[1695290629]

1695290629

[1695290629]

1695290629

[1695290629]

1695290629

[cypherdoc]

https://twitter.com/cypherdoc2/status/609716846103625728

[justusranvier]

I don't believe anyone who claims to be concerned with centralization in Bitcoin.

In general, I don't take claims about motives at face value, because people can and do lie about their motivations (usually to themselves first).

So when somebody claims to care about X, the first thing I ask myself is, "is their behavior consistent with caring about X?"

In the case of people who claim to be concerned about centralization, if that's what they care about then they should show the most concern regarding the areas of highest centralization.

There are thousands of nodes.
There are about half a dozen core developers
99% of the nodes are running on a single code base (Bitcoin Core)

Even if larger blocks reduced the node count from the thousands to the hundreds, the Bitcoin Core monoculture and development monopoly would still represent more centralization.

Anybody who expresses concern about the centralization which may or may not occur with 20 MB blocks who isn't panicking about the lack of implementation and developer diversity is motivated by something other than a preference for decentralization.

[cypherdoc]

If you're going to argue that the "original" has some kind of terribly weight to it, then you need to come to grips with all the other ways it was originally broken.

what other things did Satoshi get wrong?

[tvbcof]

If you're going to argue that the "original" has some kind of terribly weight to it, then you need to come to grips with all the other ways it was originally broken.

what other things did Satoshi get wrong?

One of the most interesting things I heard recently is Todd's exploration of the commit logs and his findings that transaction fees themselves seemed to be an after-thought hacked in a month before the initial release.  Not sure what to make of this frankly.  The two options for support after the inflation is gone would be subsidization-for-exploitation (a-la e-mail) or transaction fees.  The later made a much more palatable sales pitch to my ears.

[cypherdoc]

If you're going to argue that the "original" has some kind of terribly weight to it, then you need to come to grips with all the other ways it was originally broken.

what other things did Satoshi get wrong?

One of the most interesting things I heard recently is Todd's exploration of the commit logs and his findings that transaction fees themselves seemed to be an after-thought hacked in a month before the initial release.  Not sure what to make of this frankly.  The two options for support after the inflation is gone would be subsidization-for-exploitation (a-la e-mail) or transaction fees.  The later made a much more palatable sales pitch to my ears.

you actually still listen to that guy? 

go here and search for the word "determined" and read that sentence.  satoshi talking about it on Nov 17, 2008 before the initial release is evidence he knew all along what the transitive motivation for miners would be.  besides, a good strategy of open source coding is to get a barely working implementation of a good idea out asap so that others can pick it apart and help contribute.

https://www.mail-archive.com/cryptography%40metzdowd.com/msg10006.html

[cypherdoc]

among the other misperceptions that the anti-scaling tacticians are employing is about how Satoshi never meant for Bitcoin to reach Visa levels, or at least never considered it.  that's wrong too.  here he also talks about bandwidth:

Satoshi Nakamoto wrote:
> The bandwidth might not be as prohibitive as you
> think.  A typical transaction would be about 400 bytes
> (ECC is nicely compact).  Each transaction has to be
> broadcast twice, so lets say 1KB per transaction.
> Visa processed 37 billion transactions in FY2008, or
> an average of 100 million transactions per day.  That
> many transactions would take 100GB of bandwidth, or
> the size of 12 DVD or 2 HD quality movies, or about
> $18 worth of bandwidth at current prices.


https://www.mail-archive.com/cryptography%40metzdowd.com/msg10006.html

[justusranvier]

you actually still listen to that guy? 

go here and search for the word "determined" and read that sentence.  satoshi talking about it on Nov 17, 2008 before the initial release is evidence he knew all along what the transitive motivation for miners would be.  besides, a good strategy of open source coding is to get a barely working implementation of a good idea out asap so that others can pick it apart and help contribute.

https://www.mail-archive.com/cryptography%40metzdowd.com/msg10006.html

Is anyone keeping a list of lies told in the context of the block size limit debate?

"The number of nodes has dropped by 90%"
"Transaction fees were an afterthought added at the last minute"

[cypherdoc]

also, about this hangup about every single user being capable of running a full node:

Long before the network gets anywhere near as large as that, it would be safe
for users to use Simplified Payment Verification (section eight) to check for
double spending, which only requires having the chain of block headers, or
about 12KB per day.  Only people trying to create new coins would need to run
network nodes.  At first, most users would run network nodes, but as the
network grows beyond a certain point, it would be left more and more to
specialists with server farms of specialized hardware.  A server farm would
only need to have one node on the network and the rest of the LAN connects with
that one node.

https://www.mail-archive.com/cryptography%40metzdowd.com/msg09964.html

[cypherdoc]

you actually still listen to that guy? 

go here and search for the word "determined" and read that sentence.  satoshi talking about it on Nov 17, 2008 before the initial release is evidence he knew all along what the transitive motivation for miners would be.  besides, a good strategy of open source coding is to get a barely working implementation of a good idea out asap so that others can pick it apart and help contribute.

https://www.mail-archive.com/cryptography%40metzdowd.com/msg10006.html

Is anyone keeping a list of lies told in the context of the block size limit debate?

"The number of nodes has dropped by 90%"
"Transaction fees were an afterthought added at the last minute"

seems like a job for the Wall of Shame? 

but yes, should the core devs be held liable for any misperceptions spread?  after all, they are the stewards of the code and in a highly responsible and critical position.  Gavin understands this which is why he doesn't spend all day running his mouth on Reddit or here.

[tvbcof]

If you're going to argue that the "original" has some kind of terribly weight to it, then you need to come to grips with all the other ways it was originally broken.

what other things did Satoshi get wrong?

One of the most interesting things I heard recently is Todd's exploration of the commit logs and his findings that transaction fees themselves seemed to be an after-thought hacked in a month before the initial release.  Not sure what to make of this frankly.  The two options for support after the inflation is gone would be subsidization-for-exploitation (a-la e-mail) or transaction fees.  The later made a much more palatable sales pitch to my ears.

you actually still listen to that guy?

Sure.  I listen to everyone.  When a guy says the same thing over and over again (hint hint) it get's tedious and I tend to skim.  In the case of Peter Todd, he seems to be the among the most keenly aware that defensibly against subversion is the most critical thing to maintaining a value proposition of the blockchain which is a position I share.  He is also unusually good at spotting certain kinds of risks from a technical perspective.  I pay close attention to what he says though I don't run across him much these days.

go here and search for the word "determined" and read that sentence.  satoshi talking about it on Nov 17, 2008 before the initial release is evidence he knew all along what the transitive motivation for miners would be.  besides, a good strategy of open source coding is to get a barely working implementation of a good idea out asap so that others can pick it apart and help contribute.

https://www.mail-archive.com/cryptography%40metzdowd.com/msg10006.html

Thanks for the link (really!)  I'd not run across that particular piece of mail, or don't remember the details and timings of things if I did.  I do find it interesting that you bloatchain folks cherry pick around the concept of transaction fees so blatantly in your attempts to get everyone buying coffee with native Bitcoin.  Of course these attempts have proven a laughable failure because Bitcoin is so deficient for this kind of a role, and it's failure has nothing to do with resistance and fees neither of which has been much of a factor over the last half-decade even at the 1MB setting.

Personally I don't put a lot of emphasis on what Satoshi thought or didn't think.  Times change and people's interpretations and philosophies change.  Mine have in various substantive ways.  If Satoshi actually was one guy (or even a group of guys) whatever he may have been thinking about before 2011 may not be what he would be thinking now.  Beyond that, it is perfectly possible that whatever he was thinking then OR now is not something I would agree with.  Since I don't believe in God I don't believe that he is/was one.

On Satoshi, it is worth note that the fallout of his 1MB setting was even the half-decade, an respectable 'market cap', and a lot of attention that has interceded the system can still be brought up with a cheap storage device, an affordable network connection, a bit of power, and a place to operate where one would not end up with a bullet in the head right away.  If this happy (to me) outcome was Satoshi hoped for with his cap, good on him.  If he was clever enough to sell it to those he found gathered around him at the time by being less than complete in his rational, even better.

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.

[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.