Press J to jump to the feed. Press question mark to learn the rest of the keyboard shortcuts
Original Poster4 points · 2 months ago

You are quickly losing all authority you ever had.

What authority have I ever had? I'm just some guy that got made a target because I worked on improving privacy tech for bitcoin.

see more
15 points · 2 months ago

"Who, little old me?"

For those who aren't aware, Greg Maxwell is the co-founder and former CTO of Blockstream. He was literally the direct manager of multiple Core developers during the height of the blocksize debate.

Maxwell was also one of 5 individuals with direct commit access to the Bitcoin Core guthub repo - before he quietly removed his access due to the obvious conflict of interest that he had in being the Blockstream CTO.

Additionally, Maxwell authored the Core "scaling" roadmap, which called for Segwit and no further blocksize increase - a roadmap that is still being followed to this day.

Don't believe him when he claims he has no power over BTC. Maxwell is directly responsible for crippling BTC's capacity - setting back the adoption it global p2p currency by years.

77 points · 3 months ago · edited 3 months ago

It would have been sweet to see a 60yo 90lb Asian man driving around in an F350 😂

Yau Man was the man.

However, if Dreamz had given up immunity he would have been voted out. Yau-Man should have fought hard with Earl and D to vote out Cassandra. The edit didn’t show that he tried.

see more
16 points · 3 months ago

Yau-man didn't even need to work with Earl and Cassandra. He could have just promised Dreamz that he'd vote Cassandra himself, thus forcing at least a tie and a fire challenge for Dreamz and Cassandra. This would have let Dreamz have a chance at the finals, while also keeping his promise.

I just rewatched Fiji, and I couldn't believe that Yau didn't offer Dreamz any assurances like this. Easily Yau's biggest misplay.

jamoes commented on
-35 points · 1 year ago

Lol, blocks are average around 60 Kb. Doesn't matter if the occasional block comes in bigger. The bottom line is that virtually nobody is transacting on BCH. It's a sad state of affairs that people here seem to think that raising the limit is going to attract more users. The 8 Mb limit didn't do that and the 32 Mb limit won't either.

see more
51 points · 1 year ago

So you're saying that having a large block size limit has no effect on the actual block size? Seems like you're making a good case to just go ahead and remove the limit altogether.

41 points · 1 year ago

Now I hope we see a block larger than 8MB soon.


Personally, I'm giving the word "cash" a chance. I'm going to try using it in my everyday language, and see if I can start thinking about 0.000001 BCH as simply one "cash".

The more I think about it, the more I like it, because it matters what you call something. When you call something "cash", it becomes cash in your mind. And, in order to be interesting, bitcoin must be cash. In order to bank the unbanked, obviate central bankers, and bring about a financial renaissance, bitcoin must be cash.

So, for the next few weeks, I plan on making a conscious effort to use "cash" wherever I would have used "satoshis", or "BCH". A few simple examples:

  • Sending a transaction costs 0.01 cash per byte.

  • Posting a Memo typically costs 2 or 3 cash.

  • Buying a cup of coffee currently costs about 2000 cash.

Speaking of the price of a cup of coffee, another opportunity we have as we switch to using "cash" is to stop thinking about the price of BCH in terms of USD. If cash is to be a global ubiquitous currency, we should instead think of the price of USD in terms of cash. In other words, rather than thinking 1 BCH is currently 1450 dollars, a more effective way to think about it is that 690 cash is currently 1 dollar. This makes it easier to calculate the price of a cup of coffee (or anything) in your head.

A note about "bits": People have been trying to make "bits" stick for the past 5 years. In my opinion, it's not happening. "Bits" already means something specific in the context of computers (i.e. one "bit" is either a zero or a one). And in the context of finance, it simply sounds too similar to bitcoin itself - to the uninformed, it sounds like "bits" might just be shorthand for "bitcoin". "Cash" on the other hand has the benefit of being distinct from the name of the system.

I believe that we have a unique opportunity that has ironically been given to us by the block-size debate and the very existence of Bitcoin Cash: the opportunity to name our currency unit something that is so well-known and well-understood that every user will instantly know what it is and what it can do.

1 point · 1 year ago

At this point, I'm starting to think that BlockPress (or at least its supporters) are a concerted divide-and-conquer attack against communication protocols being built on BCH. The vote manipulation and horde of commenters parroting the "competition is good" talking point seem suspicious to me. Additionally, the developer really can't give a good reason why they broke compatibility.

Maybe I'm just being paranoid, but after seeing so many social manipulation attacks against bitcoin in recent years, I have to say that this feels like another one.

25 points · 1 year ago

What is it about “permissionless” you don’t understand? Let people try it out first. It’s nice to have good protocols, most people understand that, but people need to see for themselves if it’s worth going with one of these or another. You can’t force it. Building social consensus that way (too aggressively) is going to backfire.

see more
4 points · 1 year ago

I think you're the one misunderstanding "permisionless". We're not saying BlockPress can't create an identical-but-incompatible protocol - we're saying they shouldn't.

13 points · 1 year ago

While I appreciate the 32MB block increase, I think the real deal is the OP_RETURN to 220 bytes, we will see a LOTS of stuff in that. Counterparty will be able to run again (it was blocked back in the time by code for reducing this field), and other messaging services will allow longer message.

see more
4 points · 1 year ago

Agreed. 220 bytes is a lot more to work with. Interestingly, raising the OP_RETURN size limit isn't even a consensus rule change (i.e., it doesn't require a hard-fork).

Thanks for your feedback.

We are building a vision we had for a long time and months of work. Mistakes will be made. Of course.

There's reddit, twitter, tumblr, fb, and other networks. All serving a niche. It's not a zero sum game.

Within 2 years all major platforms will be decentralized and there is a big world for Memo and BlockPress in it.

Thank you

see more
1 point · 1 year ago

Thanks for the response. I still think it's not too late for you to change to be compatible with Memo - your protocols are still nearly identical. But, either way, I'm excited to see how you differentiate from Memo, and wish you success!

2 points · 1 year ago

We MADE it identical numbering to make it easier. Originally we had our own protocol (0x8d) with our custom numbers but then changed it to match Memo.

Take a look at how their protocol encodes txhashes, pubkey hash160 on the OP_RETURN. You will see that the protocol they use is actually not exactly the way it is published on their site.

With our 0x8d protocol, it is encoded EXACTLY like the protocol spec (no trunc/shorter hash160 address, no bitwise tx address reversal encoding) and, etc.

We will be launching the next phase of our roadmap, and will be completely meeting needs of our vision - and not someone elses (and risk of forking their protocol) Thank you,

see more
1 point · 1 year ago

Using the pubkey-hash (as Memo does) makes more sense than writing the full address into each transaction. The address includes extra bytes which aren't necessary in this context, and also ties you forever to the legacy address format. For comparison, bitcoin p2pkh transactions themselves write the pubkey-hash to the transaction - not the full address.

BTW, even though I'm posting in this thread, I definitely don't think you guys are "disgusting competition". But, I do think you're making a mistake by being incompatible with Memo. The risk of "forking their protocol" is practically zero. As long as your don't do something silly like re-use an existing action code to mean something different, I can't even see how you would fork it. If you have cool ideas to extend the protocol, just do it in a new action code! If it's cool enough, Memo will likely implement it too.

I also think it's not too late for you to change to be compatible with Memo - it's still so early in your product's life. I think it would be better for you (and Memo, and BCH as a whole) in the long run, because you'd get to share in all of Memo's existing and future network effect.

Load more comments

u/jamoesReddit Premium
Cake day
April 21, 2007
Moderator of these communities

74.4k members

Trophy Case (3)
12-Year Club

Reddit Premium

Since August 2018

Verified Email

Cookies help us deliver our Services. By using our Services or clicking I agree, you agree to our use of cookies. Learn More.