Topic: [ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread - page 378. (Read 1276826 times)

No, it is trivial to block 100% of them.  A proposal to do just that appeared on the bitcoin-development mailing list yesterday from Peter Todd.  This proposed change would relay zero transactions with multisig outputs.

Most of the world is moving to P2SH for multisig, leaving the remaining "bare multisig" users mastercoin, counterparty, etc.

Hello Luke, thank you for stopping by.  I am not clear on a few things if you do not mind.

Why do you speak of it as decided that data storage in the Blockchain constitutes abuse? How is Bitcoin actually hurt by this?
For example compared to newer protocol's Bitcoin has some massive disadvantages: an energy-inefficient proof-of-work mining system, long block times, a deflationary money supply - Newer protocols will have advantages in all of these regards (and most likely the 2.0 functionality that Counterparty has as well at some point). I would be inclined to think Bitcoin needs the added functionality to stay relevant to other rapidly developing technologies.



Miners collect fees, block rewards - and most importantly of all can decide which transactions they want to include in their blocks. Since there is #free-choice as to whether to include the transactions - I don't really understand on what grounds you put #Miners in the #Victims, #Abused category.

It's more like #Abuse of the #Users to quite arbitrarily decide for them what the protocol is and isn't to be used for.

Not exactly. Miners certainly have the ability to decide which transactions they do and don't include, but they have a duty to use that ability to protect the system from abuses.

The miners have that duty.

These are the same question.

Bare multisig transactions are not currently used. It's quite possible to turn them off without breaking anything that actually needs multisig-type use.
Furthermore, it's quite possible to determine what multisig usage is actual multisig and which are data store abuses.
So yes, there is a choice...

"Reduce"? No. OP_RETURN was increased from 0 to 40 bytes.
And no, "don't abuse us with OP_RETURN" does not mean we are forcing you to abuse us in other ways.
If we lock the windows, we aren't forcing the burglar to break them. Stop trying to blame the victim.

My apologies, I forgot to notify the community. Sergio had some other, urgent work and was delayed for a few days. The audit should be complete in the next week or two.

So far it has gone well. Phantom and Sergio have been discussing, among other things, ways of optimizing the protocol.

EDIT: When the audit is completed, there will be a blog post documenting the results.

https://www.counterparty.co/sergio-lerner-peter-todd/

I want to ask the Counterparty dev team about Sergio's audit. It was to concluded on 19th March, can someone from the team give an update on the status of the audit.

Thanks

I admit I haven't looked into any PoS scheme and any issues associated with it. NXT says its implementing some transparent forging, Ripple has consensus and Bitshares is also doing some variant of PoS. Maybe one of them will work well.

When you have an economy as large as bitcoin in your hands, you tend to be conservative when implementing changes and paranoid when considering risks. And in my opinion that's how it should be, I see no arrogance in any post TBH.

As I said before, that was a possibility from the beginning and this was (is, since nothing is broken ATM) an experiment.
If you make people choose between BTC or any other coin (including in chain), the choice is easy. Choose Bitcoin.
Having said that I will keep an eye on Bitshares and Ethereum for sure since they have the opportunity to implement things that bitcoin will take years to implement (but will do it ultimately).

PoS? PoS is not working as it should as far as I know. The PoS chains that are on the wild are usually centrally checkpointed because of security issues.

If OP_RETURN can go from 80 to 40, then it can very well go from 40 to 32 bytes if it catches their fancy. I understand why the word cabal was used in conjunction with the bitcoin core dev.

Since that particular decision is arbitrarily in the hands of people not associated with 2.0 projects I would argue that it should not be relied on even if it is possible. Our current solution works a 100% and will continue to work in future. Using OP_RETURN puts us at the mercy of people who seem to have a very rigid outlook of the future. The supposed free rides are the projects that will enrich bitcoin and make it competitive against the next generation of cryptocurrecies. Relying on the Bitcoin ecosystem to carry the day is incredibly shortsighted.

A reliable hackish solution trumps an unreliable elegant solution any day of the week and twice on Sunday.

That doesn't make sense to me.
On one hand you're introducing OP_RETURN to stop hackish and inefficient methods to store extra data in the blockchain (like using multisig outputs). On the other hand you reduce OP_RETURN to 40 bytes and say that it was never meant to be actually used – thus forcing people to continue using their hackish solutions.

Dear bitcon DEVs and all,

First a general comment: as much as i support NXT ETH etc.- Bitcoin is the real estate and gold of the entire space and is where smart money is flowing, and for a good reason. The network is well tested and strong and represent less of a risk in this very risky business. XCP and MSC being a BTC layer is a great advantage to these projects and to BTC as a whole I believe. Thus the below:  

I am very surprised to say the least from this seemingly cold shoulder.

parasites? against their will? (what does this even mean in a decentralized open source context)? whose will is it that is more important? and why? is this a centralized project suddenly?

But leaving this aside:

the BTC ecosystem is not only the applications and services such as vaults, wallets, merchant software, merchant clearing, ATMS, mining machines etc etc. These are all great and there is no doubt that great things are ahead. In a way these are external to bitcoin though are necessary to drive adaptation and penetration levels.

BUT: additional decentralized applications and platforms that allow to extend the financial capabilities and develop trustless financial products for bitcoin itself are not only a must but rather a crucial tool in extending this economy.

This will strengthen the network bring in more users and demand and many more transactions that is an interest to miners and all involved. what is against what will here?

You should be embracing and supporting these innovation clearly and loudly especially those layers on top of the BTC network. how else will this get to trillions of $$$ in penetration and transactions?

I urge all: I highly suggest that XCP devs engage in a productive dialouge with BTC devs (doesnt have to be public) to alleviate these issues and get on the same page. this cold shoulder is a shot in the feet of not only XCP and MSC but also a shot against BTC itself.  

To me the word "legitimate" is the main problem.
Who can claim the power to say: this data is legitimate and that another is not legitimate. This is called censorship!

The question can not be: What data is legitimate to be stored in the blockchain?
Because this is a subjective question, and that no one can claim to have the answer.

The only question is: Should we allow the storage of data in the blockchain?
And the answer is: there is no choice, because it is possible to do with multisig transaction.
So the question becomes: Should we let people store data in multisig transactions or provide a cleaner way to do it?

History has shown that it is much smarter to regulate than to ban something that is impossible to ban.

Thats how I see it too. The arrogance of these guys is amazing. MSC and XCP is extending the functionality of Bitcoin and may be something good have and compete with NXT, Bitshares and Ethereum.

XCP can move onto other chain, or I suggest get its on PoS chain. This will also prevent the archaic 10 minute wait.

NXT "BTS" and "Ethereum" have no robust ecosystem as BTC has.

So lets everybody with a 2.0 point of view change to NXT and eventually to Etherium! BTC is no longer cool!  

Translation : At the moment, Mastercoin and XCP are only parasites from bitcoin dev's points of view...
Sorry for being so direct but this is what I read as a non-technical investor.

Thanks Luke-Jr. Please bear with me. Although I am not the most technically bitcoin-competent, I'm trying to ask questions so we can continue to host a conversation and share further insights from bitcoin core-devs like yourself.

Maybe I'm wrong, but I am reading your words as follows: Miners will always decide their interests in what type of transactions they wish to mine. Currently, Counterparty uses multisig which are standard transactions. Although we do not wish to add to blockchain bloat, it would appear that as long as we are allowing miners to achieve their economic interests in mining all standard multisig transactions, then the system is working as it should.

Am I understanding your thoughts correctly?

If that go to this way then i think Bitcoin dev team shoot own leg in long run. New innovations choose sure other places like LTC if they make situation "development friendly" instead try kill all projects. And like XCP have make also good to Bitcoin when have burn btc:s and in theory make every bitcoin value higher and also pay miners fees so i dont see why here is not btc core team time talk about cooperation?

I haven't looked at XCP in detail yet, so I'll have to defer to others who have.

In your opinion, which category do you feel XCP falls into?

Merged mining, and/or hopefully soon bitcoin side-chains.

Because:

• Too many people were getting the impression that OP_RETURN was a feature, meant to be used. It was never intended as such, only a way to "leave the windows unlocked so we don't need to replace the glass when someone breaks in". That is, to reduce the damage caused by people abusing Bitcoin.
• 40 bytes is more than sufficient for all legitimate needs for tying data to a transaction: you get 32 bytes for a hash, plus 8 bytes for some kind of unique identifier (which really isn't necessary either!).
• The original 80 byte proposal was intended to be for 512-bit hashes, but this was determined to be unnecessary.

Zero bytes is exactly how it's intended to be.
Note the OP_RETURN change by the development team is only a change in default relay policy.
Miners are, as always, expected to make their own policy decisions, and never rely on merely the default Bitcoin Core mining code.
Hopefully as mining returns to being decentralised, we will see less toleration of abusive/spam transactions whether the OP_RETURN variant or otherwise.
Now, if someone has a valid, necessary use case for actually storing hashes with transactions, obviously that's a case miners should seriously consider mining.