Author

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

sr. member
Activity: 262
Merit: 250
I'm sorry, what's the problem with changing the limit in IsStandard() back to 80 bytes? I have yet to see any argument for why 40 is better than 80, and using the latter value would benefit everyone involved immediately.
For relay, probably no immediate problem.
For mining, it encourages spam.
For long-term, it's unnecessary.

Edit: Except that relaying transactions which will never be mined is currently exploitable. So either that would need to be fixed first, or the relay needs to be more intelligent and only relay Counterparty transactions the same way miners would mine them.

If the issue is spam control, then wouldn't that be negated a variable fee based upon based upon the level of risk that spam may be contained within the transaction? Such a variable fee in this case is non-linear to the amount of 'risky' data attached. It would remove the arbitrary nature of 40 or 80 bytes.

It is difficult to predict what is necessary or unnecessary in the future. What if I wish to publish into the ledger the the daily fixings of the history of a 500 million dollar notional interest rate swap. Perhaps at that juncture in the future we would decide it was inappropriate to be stored in the blockchain. However, if it was appropriate I would certainly be willing to pay a larger premium to place it into the ledger.
legendary
Activity: 2576
Merit: 1186
I'm sorry, what's the problem with changing the limit in IsStandard() back to 80 bytes? I have yet to see any argument for why 40 is better than 80, and using the latter value would benefit everyone involved immediately.
For relay, probably no immediate problem.
For mining, it encourages spam.
For long-term, it's unnecessary.

Edit: Except that relaying transactions which will never be mined is currently exploitable. So either that would need to be fixed first, or the relay needs to be more intelligent and only relay Counterparty transactions the same way miners would mine them.
sr. member
Activity: 476
Merit: 300
Counterparty Chief Scientist and Co-Founder
Redesigning the protocol to make it better is one thing. Trying to shoehorn it into a completely arbitrary 40-byte space is not.
I'm not suggesting trying to shrink it to 40 bytes.
I'm suggesting keeping the current 80-byte OP_RETURN implementation in the short-term, and building an upgrade for the long-term using a side-chain (ideally collaborative with Freimarkets, since they seem to be doing the same thing).

We're not talking about forcing anyone to do anything. We're talking about the default relay policy for Bitcoin Core. If it were a matter of forcing anyone to do anything, why would a 40-byte OP_RETURN OK and not an 80-byte OP_RETURN (again, the original, publicly-announced, merged-into-the-codebase plan)?
40-byte OP_RETURN is potentially unavoidable for some things (no, I don't know any examples).
Once there is a patch that relays Counterparty transactions (and not spam), you're certainly free to open a merge request for mainline as well.
You might have better success, if the patch is also able to understand Counterparty protocol and not relay invalid Counterparty transactions.

We're not going to regress from relaying our transactions through the main Bitcoin network to relaying them, through central points of failure, directly to some subset of mining pools that have specifically whitelisted us with a patch. We won't depend on any feature not supported by vanilla Bitcoin Core, even if it means storing the message data in unprunable, (or even unspendable!) outputs for the time being.
Then you give us no choice but to add better filters to keep out the abuse.

I'm sorry, what's the problem with changing the limit in IsStandard() back to 80 bytes? I have yet to see any argument for why 40 is better than 80, and using the latter value would benefit everyone involved immediately.
full member
Activity: 224
Merit: 100
CabTrader v2 | crypto-folio.com
newbie
Activity: 17
Merit: 0
We're not talking about forcing anyone to do anything. We're talking about the default relay policy for Bitcoin Core. If it were a matter of forcing anyone to do anything, why would a 40-byte OP_RETURN OK and not an 80-byte OP_RETURN (again, the original, publicly-announced, merged-into-the-codebase plan)?
40-byte OP_RETURN is potentially unavoidable for some things (no, I don't know any examples).

The answer is stealth addresses, which fit nicely in 40 bytes, are completely random by design (so are incompatible with semantic filtering) and add significant value to the network. I'd like to know why you are so engaged in this conversation, when you don't know about probably the most talked about use-case for the feature under discussion? In fact, why are you trying so hard to influence default relay policy, which has no direct effect on 'blockchain spam', when your aims would be better served by convincing other miners that you're right?
legendary
Activity: 2576
Merit: 1186
Redesigning the protocol to make it better is one thing. Trying to shoehorn it into a completely arbitrary 40-byte space is not.
I'm not suggesting trying to shrink it to 40 bytes.
I'm suggesting keeping the current 80-byte OP_RETURN implementation in the short-term, and building an upgrade for the long-term using a side-chain (ideally collaborative with Freimarkets, since they seem to be doing the same thing).

We're not talking about forcing anyone to do anything. We're talking about the default relay policy for Bitcoin Core. If it were a matter of forcing anyone to do anything, why would a 40-byte OP_RETURN OK and not an 80-byte OP_RETURN (again, the original, publicly-announced, merged-into-the-codebase plan)?
40-byte OP_RETURN is potentially unavoidable for some things (no, I don't know any examples).
Once there is a patch that relays Counterparty transactions (and not spam), you're certainly free to open a merge request for mainline as well.
You might have better success, if the patch is also able to understand Counterparty protocol and not relay invalid Counterparty transactions.

We're not going to regress from relaying our transactions through the main Bitcoin network to relaying them, through central points of failure, directly to some subset of mining pools that have specifically whitelisted us with a patch. We won't depend on any feature not supported by vanilla Bitcoin Core, even if it means storing the message data in unprunable, (or even unspendable!) outputs for the time being.
Then you give us no choice but to add better filters to keep out the abuse.
legendary
Activity: 882
Merit: 1000
Personally, I think we can evaluate the possibility to compress our most transactions to 40 bytes now. If it is possible, it's better to do it now cause no real OP- RETURN has been used in main net yet and no need to worry about backward compatibility.

I agree that to force it to fit 40 bytes introduces a lot of unnecessary work, but anyway reducing the block chain size is beneficial to the bitcoin in the long term.

A tx = flag + asset id + amount + price + expire + fee ... I think it's doable to encode them in a space efficient way.
sr. member
Activity: 476
Merit: 300
Counterparty Chief Scientist and Co-Founder
Redesigning the protocol to make it better is one thing. Trying to shoehorn it into a completely arbitrary 40-byte space is not.
I'm not suggesting trying to shrink it to 40 bytes.
I'm suggesting keeping the current 80-byte OP_RETURN implementation in the short-term, and building an upgrade for the long-term using a side-chain (ideally collaborative with Freimarkets, since they seem to be doing the same thing).

We're not talking about forcing anyone to do anything. We're talking about the default relay policy for Bitcoin Core. If it were a matter of forcing anyone to do anything, why would a 40-byte OP_RETURN OK and not an 80-byte OP_RETURN (again, the original, publicly-announced, merged-into-the-codebase plan)?
40-byte OP_RETURN is potentially unavoidable for some things (no, I don't know any examples).
Once there is a patch that relays Counterparty transactions (and not spam), you're certainly free to open a merge request for mainline as well.
You might have better success, if the patch is also able to understand Counterparty protocol and not relay invalid Counterparty transactions.

We're not going to regress from relaying our transactions through the main Bitcoin network to relaying them, through central points of failure, directly to some subset of mining pools that have specifically whitelisted us with a patch. We won't depend on any feature not supported by vanilla Bitcoin Core, even if it means storing the message data in unprunable, (or even unspendable!) outputs for the time being.
legendary
Activity: 2576
Merit: 1186
Redesigning the protocol to make it better is one thing. Trying to shoehorn it into a completely arbitrary 40-byte space is not.
I'm not suggesting trying to shrink it to 40 bytes.
I'm suggesting keeping the current 80-byte OP_RETURN implementation in the short-term, and building an upgrade for the long-term using a side-chain (ideally collaborative with Freimarkets, since they seem to be doing the same thing).

We're not talking about forcing anyone to do anything. We're talking about the default relay policy for Bitcoin Core. If it were a matter of forcing anyone to do anything, why would a 40-byte OP_RETURN OK and not an 80-byte OP_RETURN (again, the original, publicly-announced, merged-into-the-codebase plan)?
40-byte OP_RETURN is potentially unavoidable for some things (no, I don't know any examples).
Once there is a patch that relays Counterparty transactions (and not spam), you're certainly free to open a merge request for mainline as well.
You might have better success, if the patch is also able to understand Counterparty protocol and not relay invalid Counterparty transactions.
sr. member
Activity: 476
Merit: 300
Counterparty Chief Scientist and Co-Founder
Counterparty requirements
1) 80 bytes of data
2) Counterparty transactions are relayed through the network as normal transactions

Do you think it is possible to reach an agreement from your side on how we can achieve these requirements? If so can you think how this could be possible?
I don't think those requirements are reasonable.
Why does it matter how much data XCP can use, or how the transactions are relayed?
What should matter is that people can use it for A, B, and C goals.
The technical side is just a matter of implementation, not requirement.
We need at least 80 bytes because that's the limit the Counterparty protocol was designed around.
Expect to have to change the protocol at some point.
No offence intended (this is expected in ordinary development), but the current one is at best a "first draft".

The solution you proposed is hackish and political, and needlessly so.
If you mean the predefined relays, yes, it is a bit hackish. As is the current protocol generally.
But it will work in the short-term, while a better protocol for upgrading to can be designed.

We need a simple, robust and standard way of relaying our transactions through the normal and fully decentralised Bitcoin network. We need for our system to have as few points of failure as possible.
Forcing others to provide services is not justified by the "need" for it.


Redesigning the protocol to make it better is one thing. Trying to shoehorn it into a completely arbitrary 40-byte space is not. 40 bytes is probably just too little for what we want to do anyway---for what we are already doing. In the short-term, CheckMultiSig works just fine for us. It's much easier, better, cleaner and safer to switch encoding mechanisms (which there are also a million of) than to shrink every message in the protocol in a backwards-incompatible fashion... (again) for no reason.

We're not talking about forcing anyone to do anything. We're talking about the default relay policy for Bitcoin Core. If it were a matter of forcing anyone to do anything, why would a 40-byte OP_RETURN OK and not an 80-byte OP_RETURN (again, the original, publicly-announced, merged-into-the-codebase plan)?
legendary
Activity: 2576
Merit: 1186
Wait for Zerocoin to boot BTC out.
You prefer an altcoin that requires centralised trust, over a decentralised Bitcoin? Smiley
Decentralized Bitcoin, which requires getting the permission of ~15 powerful individuals in order to have transactions confirmed; transactions which fully comply with the existing Bitcoin specifications and implementations?
Nobody is forcing you to run the reference client.
Fork it. Please.

And no, the Counterparty writeup is not an "existing Bitcoin specification".
For that claim, the developers should collaborate with the existing Bitcoin development community to formally define a BIP.
full member
Activity: 214
Merit: 101
Wait for Zerocoin to boot BTC out.
You prefer an altcoin that requires centralised trust, over a decentralised Bitcoin? Smiley

Decentralized Bitcoin, which requires getting the permission of ~15 powerful individuals in order to have transactions confirmed; transactions which fully comply with the existing Bitcoin specifications and implementations?

Since OP_Return was reduced to 40 bytes right before the release of .9, Counterparty is currently using Multi-sig (which was supposed to be deprecated) which is undesirable for reasons aforementioned by Peter Todd. On the other hand I do not think I've seen anyone present a line of technical reasoning as to why OP_Return 40 is alright while OP_Return 80 is undesirable.
hero member
Activity: 700
Merit: 500
Wait for Zerocoin to boot BTC out.
You prefer an altcoin that requires centralised trust, over a decentralised Bitcoin? Smiley

Decentralized Bitcoin, which requires getting the permission of ~15 powerful individuals in order to have transactions confirmed; transactions which fully comply with the existing Bitcoin specifications and implementations?
member
Activity: 61
Merit: 10
Counterparty requirements
1) 80 bytes of data
2) Counterparty transactions are relayed through the network as normal transactions

Do you think it is possible to reach an agreement from your side on how we can achieve these requirements? If so can you think how this could be possible?
I don't think those requirements are reasonable.
Why does it matter how much data XCP can use, or how the transactions are relayed?
What should matter is that people can use it for A, B, and C goals.
The technical side is just a matter of implementation, not requirement.

We need at least 80 bytes because that's the limit the Counterparty protocol was designed around.

The solution you proposed is hackish and political, and needlessly so. We need a simple, robust and standard way of relaying our transactions through the normal and fully decentralised Bitcoin network. We need for our system to have as few points of failure as possible.
So don't u mean if bitcoin core devs insist on 40 bytes, XCP will be gradually dead?

No, not at all.

So what would happen to XCP if 40 bytes limit is imposed?
sr. member
Activity: 476
Merit: 300
Counterparty Chief Scientist and Co-Founder
Counterparty requirements
1) 80 bytes of data
2) Counterparty transactions are relayed through the network as normal transactions

Do you think it is possible to reach an agreement from your side on how we can achieve these requirements? If so can you think how this could be possible?
I don't think those requirements are reasonable.
Why does it matter how much data XCP can use, or how the transactions are relayed?
What should matter is that people can use it for A, B, and C goals.
The technical side is just a matter of implementation, not requirement.

We need at least 80 bytes because that's the limit the Counterparty protocol was designed around.

The solution you proposed is hackish and political, and needlessly so. We need a simple, robust and standard way of relaying our transactions through the normal and fully decentralised Bitcoin network. We need for our system to have as few points of failure as possible.
So don't u mean if bitcoin core devs insist on 40 bytes, XCP will be gradually dead?

No, not at all.
sr. member
Activity: 262
Merit: 250
I agree with what you said. Is it correct that we are not at the stage where the fee can be distributed across the network? At the moment those fees we are talking about would be taken by the miners but there is nothing to stop those fees disbursed across the network in the future.
It's possible. Whether it's practical, is another more complicated issue Sad

Am I correct to say that we don't disagree that:
1) Counterparty messages are financial transactions
2) There is scope to include Counterparty messages in the blockchain as long as :
  a) It doesn't cause undue burden on the network
  b) It doesn't open the door for other abuses of data storage in the blockchain
This seems fair.

Counterparty requirements
1) 80 bytes of data
2) Counterparty transactions are relayed through the network as normal transactions

Do you think it is possible to reach an agreement from your side on how we can achieve these requirements? If so can you think how this could be possible?
I don't think those requirements are reasonable.
Why does it matter how much data XCP can use, or how the transactions are relayed?
What should matter is that people can use it for A, B, and C goals.
The technical side is just a matter of implementation, not requirement.

Unfortunately, if Counterparty transactions were relayed only as nonstandard transactions, it creates a large nonfunctional issue where the time between Counterparty transactions would become unnecessarily large. Perhaps this would be negated if other miners were to agree to then but then we end up with a suboptimal solution been widely accepted.

I'd like to see a solution which meets the requirements we are asking and also gives the miners the choice if they were to include the transaction in the block.
newbie
Activity: 12
Merit: 0
Counterparty requirements
1) 80 bytes of data
2) Counterparty transactions are relayed through the network as normal transactions

Do you think it is possible to reach an agreement from your side on how we can achieve these requirements? If so can you think how this could be possible?
I don't think those requirements are reasonable.
Why does it matter how much data XCP can use, or how the transactions are relayed?
What should matter is that people can use it for A, B, and C goals.
The technical side is just a matter of implementation, not requirement.

We need at least 80 bytes because that's the limit the Counterparty protocol was designed around.

The solution you proposed is hackish and political, and needlessly so. We need a simple, robust and standard way of relaying our transactions through the normal and fully decentralised Bitcoin network. We need for our system to have as few points of failure as possible.
So don't u mean if bitcoin core devs insist on 40 bytes, XCP will be gradually dead?
legendary
Activity: 2576
Merit: 1186
Counterparty requirements
1) 80 bytes of data
2) Counterparty transactions are relayed through the network as normal transactions

Do you think it is possible to reach an agreement from your side on how we can achieve these requirements? If so can you think how this could be possible?
I don't think those requirements are reasonable.
Why does it matter how much data XCP can use, or how the transactions are relayed?
What should matter is that people can use it for A, B, and C goals.
The technical side is just a matter of implementation, not requirement.
We need at least 80 bytes because that's the limit the Counterparty protocol was designed around.
Expect to have to change the protocol at some point.
No offence intended (this is expected in ordinary development), but the current one is at best a "first draft".

The solution you proposed is hackish and political, and needlessly so.
If you mean the predefined relays, yes, it is a bit hackish. As is the current protocol generally.
But it will work in the short-term, while a better protocol for upgrading to can be designed.

We need a simple, robust and standard way of relaying our transactions through the normal and fully decentralised Bitcoin network. We need for our system to have as few points of failure as possible.
Forcing others to provide services is not justified by the "need" for it.
sr. member
Activity: 476
Merit: 300
Counterparty Chief Scientist and Co-Founder
Counterparty requirements
1) 80 bytes of data
2) Counterparty transactions are relayed through the network as normal transactions

Do you think it is possible to reach an agreement from your side on how we can achieve these requirements? If so can you think how this could be possible?
I don't think those requirements are reasonable.
Why does it matter how much data XCP can use, or how the transactions are relayed?
What should matter is that people can use it for A, B, and C goals.
The technical side is just a matter of implementation, not requirement.

We need at least 80 bytes because that's the limit the Counterparty protocol was designed around.

The solution you proposed is hackish and political, and needlessly so. We need a simple, robust and standard way of relaying our transactions through the normal and fully decentralised Bitcoin network. We need for our system to have as few points of failure as possible.
full member
Activity: 214
Merit: 101

You deleted my posts because I keep telling the truth

I would guess it's because you are using yet another alt to post scrap.
Jump to: