Gold collapsing. Bitcoin UP.

[Bagatell]

I was wondering when this would blow up.

https://old.reddit.com/r/btc/comments/92to5q/what_are_the_plans_for_other_clients_node/

 

[satoshis_sockpuppet]

WTF is wrong with you @deadalnix ..
Even I was aware, that people were building Graphene on BU and I'm not a dev. IIRC there were reddit threads months ago about that. And the pull request was open for quite a while.

NIH syndrome in an extreme form.

 

[awemany]

Hey folks,

was just reading the discussion here about group- vs. OP_RETURN-based tokens. As you might know, I am rather sceptical as to the value of 'fully on chain validated' tokens (a.k.a. OP_GROUP and similar) as well as also the general hype about Ethereum's Turing completeness.

Bitcoin has the better and more thoughtful approach to on-chain computation (Turing completeness when you include the incentivized endpoints). I have yet to see one single sound argument why Ethereum's approach is better that does not amount to mere hype.

Bitcoin's approach keeps the complexity out of the protocol and moves it towards the endpoints. See also the internet protocol, for example. Given that Bitcoin deals with a single global shared state, complexity in the main protocol is an enemy of scalability.

And IMO very similar things happen for tokens here.

That said, let me pick this post by @Norway as a starting point to ask a bit deeper, as I still don't really get what kind of governance issue 'on-chain-validated' tokens will solve that isn't already solved by what we have right now:

The two differences between OP_RETURN-tokens and GROUP-tokens are:

1) Miners validate the GROUP-transaction, just like BCH transactions.

Miners validate OP_RETURN tokens as well. They time stamp them. In essence, a major part of Bitcoin is an incentivized time stamping service. The incentive to run it stems from the token that is being dealt with that timestamping service (BCH).

In both cases, there are pieces of data that you interpret as having value. In case of BCH the blockchain protocol is the agreed-upon interpretation, in case of an OP_RETURN token, the OP_RETURN protocol is the agreed-upon interpretation. In both cases, the validity of the token is nothing more and nothing less than a mutual agreement of the parties involved.

But note that the timestamping, which makes transfers and assignment of tokens possible, happens for both BCH as well as your TOK OP_RETURN tokens.

2) Miners keep the GROUP tokens secure. Very hard to take down.

In what sense do they keep them secure? What kind of take down do you have in mind here?
How would a take down work for OP_RETURN that does not work for OP_GROUP? Please paint a realistic scenario.

The OP_RETURN tokens are just too weak if put under attack (sybil, DOS) from an outside force. They work - until they don't.

Can you make a realistic scenario for a Sybil attack and a scenario for a DOS attack that you are thinking of here? I really fail to see how this is possible.

Let's assume that it's normal to mix/shuffle your stock (digital bearer share) issued as a GROUP token the second after you receive it the first time. The mixer is built into your SPV wallet.

At this point, the issuer has no longer a record of who owns what. He can not provide any relevant KYC to governments, and he can not go after a single shareholder. If he refuse to redeem (refuse to pay dividends or refuse shareholders to vote) he will do this to the shareholders as a group. No blacklisting is possible.

I can see coin shuffle schemes very similar to how they run on BCH working just fine using OP_RETURN based tokens as well. What prevents mixing/shuffling of OP_RETURN tokens?

Arguably, OP_RETURN tokens that work by storing just a hash of the token transaction in the chain are even a bit better than group tokens in this regard, as there will be less world-readable data on the chain. (But I do fully support Jonald et al.'s SLP approach).

 

[lunar]

@awemany

Not that my opinion is worth anything - miners must be the ones to decide, but I'm a firm believer in "Don't touch the base protocol, you fools"

This looks like a promising approach.

https://bitsonline.com/keoken-bitcoin-cash-commerce-protocol/

"The Keoken platform, a new second-layer protocol set to widely broaden the types of commerce possible via the underlying Bitcoin Cash blockchain. The second-layer protocol will give BCH a “smart layer” capable of rivaling the commerce capabilities of Omni, Ethereum, and Bitcoin’s RSK."

 

[cypherdoc]

leave the base protocol alone

 

[bitsko]

Hashrate governance is not some strange idea that came out of nowhere, it is literally how people with real skin in the game (of the type that requires continual investment, binding them ever closer to the game) can make decisions.

The biggest failing with BTC imo is that these entrepreneurs were not engaged at that level.

 

[Norway]

@awemany

Miners validate OP_RETURN tokens as well. They time stamp them.

To time stamp an OP_RETURN message is not the same as to validate it.

If I post on Memo the string "Awemany transfers his stocks to Norway", the transfer of stocks is neither validated nor enforced by the miners. So if they don't do it, who's doing it?

In what sense do they keep them secure? What kind of take down do you have in mind here?
How would a take down work for OP_RETURN that does not work for OP_GROUP? Please paint a realistic scenario.

My answer to this is quoted just under your question: "The OP_RETURN tokens are just too weak if put under attack (sybil, DOS) from an outside force. They work - until they don't."

Can you make a realistic scenario for a Sybil attack and a scenario for a DOS attack that you are thinking of here? I really fail to see how this is possible.

This is basically the same question you repeat. I'll try to answer more in depth, but I'm not a hacker:

If the tokens are administrated by a network of computers outside the mining nodes, it will be just as easy to attack as any network of computers. If the computers should for some reason disagree in what the truth is because of attacks, there is no way to settle the dispute.

I agree that we shouldn't make BCH a lot more complex just to add a small feature. But as far as I understand, GROUP is more like a small tweak to the protocol that give a lot of bang for the buck.

GROUP has the potential to revolutionize how stocks are issued, traded and regulated today to a more free market where gatekeepers have less power.

As an investor, I like that value proposal.

 

[Christoph Bergmann]

I want to throw in a little announcement for the German readers of this thread (I know you exist :

I published a book, "Bitcoin: Die verrückte Geschichte vom Aufstieg eines neuen Geldes". It covers everything about Bitcoin, the technology, the monetary revolution, the politics; it also covers a lot of stories, from Mt. Gox to Silk Road to the blocksize wars. I think it is the first book ever that writes about the blocksize wars and so on.

If you are interested, please visit the site of the book, where you get a lot more information and can pay it with Bitcoin Cash (or Bitcoin or Euro).

http://bitcoin-buch.org/index.html

 

[awemany]

@awemany


To time stamp an OP_RETURN message is not the same as to validate it.

If I post on Memo the string "Awemany transfers his stocks to Norway", the transfer of stocks is neither validated nor enforced by the miners. So if they don't do it, who's doing it?

If I send you 1.0 BCH, all I get is a bit of data in some distributed database that said I did and which you and I both interpret as being 'valid'. So where is the difference to tokens?

My answer to this is quoted just under your question: "The OP_RETURN tokens are just too weak if put under attack (sybil, DOS) from an outside force. They work - until they don't."

Fair enough, so if I understand you correctly only DOS and sybil attacks are the scenarios that you are worried about?

If the tokens are administrated by a network of computers outside the mining nodes, it will be just as easy to attack as any network of computers. If the computers should for some reason disagree in what the truth is because of attacks, there is no way to settle the dispute.

No, that is not a problem. Let's take my own proof-of-concept SITO or Jonald's SLP or probably most other OP_RETURN-based systems. Each token has a genesis (the initial token transaction) and is linked to an output on the BCH chain that you need to spend to spend the token.

The token systems work by referring back to the POW-secured BCH chain for spending tokens. Only tokens that follow the OP_RETURN chain in BCH are valid and only tokens that are correlated with a corresponding BCH output are spendable, by whoever owns the corresponding keys.

So what exactly is DOSsable or Sybil-able here?

Maybe I miss what you are saying here - if so, please make your sybil or DOS scenario more specific.

@Christoph Bergmann : Sounds very interesting, I'll check it out!

 

[Mengerian]

WTF is wrong with you @deadalnix ..
Even I was aware, that people were building Graphene on BU and I'm not a dev. IIRC there were reddit threads months ago about that. And the pull request was open for quite a while.

NIH here syndrome in an extreme form.

There must have been some sort of communication disconnect. It came as a surprise to me when I heard Graphene was merged, so I can see how others were surprised also.

I think the point that Amaury was making is that if the people working on something that they want to be implemented across several implementations, it's best if they reach out to the different groups at the design stage, make sure they are aware, and get review and feedback on the design and implementation details.

It makes things awkward if you get presented with a complete basically "finished product". Then if you have some different opinions or specific concerns about design decision, you have choice between accepting a design you're not happy with, or doing something different and getting accused of NIH syndrome. It's much better to try to work through all the concerns of different groups at the design stage. You're also more likely to end up with a robust design that way.

In the case of Graphene, I'm not sure what the disconnect was. But I'm hopeful we're still at an early enough stage where it's still considered experimental, and the protocol specification is open to tweaks based on feedback (if needed). It probably makes sense to wait until Canonical order is enforced before finalizing the protocol anyway.

 

[satoshis_sockpuppet]

There must have been some sort of communication disconnect. It came as a surprise to me when I heard Graphene was merged, so I can see how others were surprised also.

Well, either that, or deadalnix is our Greg Maxwell who wants to control very development in BCH.

If the inventors of Graphene had decided to implement Graphene in ABC and not BU, do you really believe deadalnix would give a fuck about how BU gets a chance to implement it? He takes every chance he gets to piss on BU's work and now that BU has merged a new feature before his implementation, he goes full Maxwell and tries to kick out BU instead of trying to merge Graphene into ABC.

Why all the fuss? He and the ABC team could now start to implement Graphene in ABC instead to piss off everybody and start their own implementation which must be incompatible because.. well the BU version is not invented by deadalnix.. (remember compact blocks / xthin?)

His "fuck every other implementation" and the "I'm a superstar dev" attitude is such a fat red warning light.

He did deliver a robust first client for BCH. That's his past merit. Other than that, he is a nobody.

Never forget, it's the miners, not the devs.

 

[awemany]

@Mengerian : It seems that Graphene as it is right now is working great with the -granted- still limited testing it has seen so far.

However, I have already given some feedback to George Bissias, I think that there's another 25% or so that can be saved by making some of the fields in the CIblt structure smaller or dropping them altogether. For example the checksum field can likely be shortened to 16-bit or maybe even 8-bit or so (depending on the statistics and a retransmission/size trade-off) and also the Iblt is purely used as a set (no values) right now and thus the empty value vectors could be dropped.

I think that's something for the 2nd iteration, though. But maybe that's the iteration where other implementations will incorporate it as well. I totally agree with everyone that Graphene needs to be properly documented, but that is underway.

I also have already submitted a patch to George for a uint64_t (compactly encoded, so currently just a byte) in the CIBlt structure, for versioning that one given that the above optimizations are foreseeable. He included it. I'll do my best to add some other ones to the other Graphene structures.

I don't really see any harm in having 'experimental version zero' of Graphene out there. Remember, it is only activated in BU after setting a switch. And an upgrade of the dev tree breaking it should come as not a big surprise to anyone right now.

The only potential problem that I can see is that the current version ossifies, without a good way to upgrade it. But IMO this can be fully addressed with versioning the specific data structures.

 

[cypherdoc]

I want to throw in a little announcement for the German readers of this thread (I know you exist :

I published a book, "Bitcoin: Die verrückte Geschichte vom Aufstieg eines neuen Geldes". It covers everything about Bitcoin, the technology, the monetary revolution, the politics; it also covers a lot of stories, from Mt. Gox to Silk Road to the blocksize wars. I think it is the first book ever that writes about the blocksize wars and so on.

If you are interested, please visit the site of the book, where you get a lot more information and can pay it with Bitcoin Cash (or Bitcoin or Euro).

http://bitcoin-buch.org/index.html

Why no English version ?

 

[awemany]

@Christoph Bergmann: Bug report! Your website for the book has a default selection for payment of BTC and not BCH!

 

[Christoph Bergmann]

Why no English version ?

That's a simple and complicated question. In English there are so many books about Bitcoin, in German so few; also my English is far from being sufficient to write in English; and how the fuck can you ship books to the USA or to Japan? If it becomes a bestseller in Germany, I'll think about investing in a translater and shipping partners ... but I doubt this happens ...

@awemany: When I tested, Bitcoin Cash was default currency. But I stepped back from this, because my audience mostly uses Bitcoin (Core). Payments are mostly made in Fiat, than in Bitcoin (Core), and a very low number in Bitcoin Cash and Ethereum. Unfortunately.

 

[79b79aa8]

Not the best scarcity guarantees. Can you ever really be sure those minting keys are inaccessible?

wormhole minting is governed by proof of burn, so that's not the issue. now if issuer disappears and you are left with dumb tokens, could they acquire value superior to the corresponding BCH? unlikely, as the token will hardly have the same useability for payments and market penetration than the coin itself.

what i am failing to understand are use cases. can anyone foresee?

 

[Tomothy]

Happy independence day.

Re Wormhole, I'm having some trouble understanding it as well. I haven't seen anyone make a token yet or showed how the token works. I'm sure coinex launches a CET token on whc soon though and then we can see the inner workings.

Watching stuff on wallet.keoken.io is crazy though. Knowing the cost of the keoken token would help evakeval this as well.

 

[lunar]

Happy liberation day.

[doublepost=1533207070][/doublepost]

 

[Bloomie]

The forum's server has been down intermittently for the past 14 hours or so. If the site is inaccessible, that's the reason. I have a team working on it.

P.S. Happy BCH Day.

 

[79b79aa8]

poking GROUP
https://www.yours.org/content/open-letter-to-andrew-stone--bu-team-or-anyone-who-is-already-sold-on-d97a54f15182