The formula for gas cost should reflect the deflation of burned XCP because otherwise running contracts would slowly increase the cost.
And most important; it would eventually result in running out of XCP because if it still costs 1 XCP to run a contract once we only have 1 XCP left then we’d be done …
Burning BTC makes the above a lot more complex, if the BTC goes 2x then contracts become 2x as expensive.
In contrary to XCP, the BTC price won’t be influenced much by the cost of running a smart contract, while the XCP price will be influenced by it because apart from speculation it’s the only other variable for it.
Did you mean XCP have already burnt from BTC and thats why it is only way burn BTC for running Ethereum Smart Contracts with Counterparty platform over Bitcoin blockchain? And Bitcoin developers need accept that some beautiful day and stop to think XCP is just altcoin?
If it were me, I’d calculate the XCP burn price first, as you proposed.
Let’s say it’s 0.01 XCP to exec a contract.
Then you’d dynamically calculate a BTC burn price based on what the equivalent amount is in BTC.
Let’s say 1 XCP is trading for 0.5 BTC. In this case, it would take a 0.005 BTC burn.
I gather establishing the BTC price is the easy part. The hard part is what happens after the BTC has been burned. Whatever the case may be, it should never touch the XCP supply.
“Should” is just an opinion without a reason. It seems an odd choice to prefer BTC; and frankly only those outside of CounterParty would propose that. It is in CounterParty’s interest that XCP is an attractor; use of XCP will help support the entire ecosystem. There is no downside to using XCP; there are downsides to prefering BTC or any other currency above XCP. CounterParty should stand by its own core currency and see others as unequal.
The calculation of the equivalence in BTC, will allow others to use their BTC, in the same way as all others currency can be calculated before it becomes the XCP gas.
The market cap of XCP is under $10M. Most people are “outside” of XCP.
And Counterparty isn’t Ethereum. We didn’t pocket $30M to pay for full-time developers. Ethereum was able to make up for the altcoin stigma with economic strength, which Counterparty is severely lacking.
However, burning BTC is a huge advantage Counterparty retains over Ethereum. That is how you bring the network effect to Counterparty without raising $30M.
Counterparty can’t escrow BTC directly. XCP and native assets will always be the only first class citizens in the protocol. This is an inherent reality of the platform.
Another possibility is to make BTC burns more costly compared to XCP burns to account for the UTXO bloat premium. But note that it’s very conceivable Bitcoin Core will take care of making the BTC burns more costly by discriminating against burns in various ways. Still, a simple multiplier to encourage XCP burns over BTC burns is feasible.
@Consensus There is a technical reason why BTC cannot be used. AFAIK the contract address must be pre-filled with gas (i.e. XCP) and small chunks of XCP will be destroyed as the contract executes. This is equivalent to gasoline in an engine, hence the word gas. I agree BTC would be ideal but unfortunately it is impossible to use BTC as gas.
@rubensayshi I agree, the gas price must reflect deflation. Be careful not to make the equation too simple though. If the gas price were to strictly fall proportionally to the XCP supply, problems would occur as the XCP price in USD (or EUR) fluctuates. E.g. in one year the supply is 1% less while the XCP price is $0.50. Or $50. In the first case it would be cheap to flood the system. In the latter - too expensive to use it all.
I propose we set a band of reasonable amount of calculations globally. By calculations I mean the average gas units consumed per block. The exact formula is earlier in this thread, and the weights are copied from Ethereum.
If more than a reasonable amount of calculations are executed, then the gas price will be adjusted down.
If less executions, adjust the price up.
This solves the deflation problem AND the XCP price in dollars problem.
Also, if by reasonable we mean about one second of execution time for a normal server, then even a temporary 10x higher usage will not really cause much harm - only temporary cause a 10 sec delay. Soon enough the price will adjust up and usage will be forced down again. An attacker will likely not even try because the disruptions will be negligible.
Later changing the magic thresholds for reasonable amount will require a hard fork. It’s not ideal, ref. the 1 MB block debate, but I cannot think of any better solution. A real market mechanism is not possible. No one sells computing power; servers run for free. A voting mechanism (as in Ethereum) is impossible since there are no miners, and also a vote by community is likely not a good idea. Most people wouldn’t care to vote, so a small minority could attack the network.
@rubensayshi right: the protocol should go by the DEx quoted BTC/XCP trading pair, likely weekly EMA. Fully agreed on not using a centralized exchange. With the DEx, it’d be native to the Counterparty protocol.
Note using the DEx to establish the BTC gas burn rate doesn’t affect the XCP gas burn rate at all. So if anything goes wrong there, it’s just more incentive to acquire XCP. I also cannot overstate the importance of the headline “Exec Ethereum contracts on Bitcoin mainchain with BTC today”. Strategically it’s critical for Counterparty to gain developer mindshare, and you don’t do that by limiting entry only to XCP holders. That makes Counterparty into just another altcoin that no one takes seriously.
Also, with the DEx pricing, they can only manipulate the BTC gas burn price by adding liquidity to the DEx, and by doing so they’re just increasing Counterparty’s network effect and bringing activity to the most valuable trading pair.
In my book, that’s a Win-Win-Win situation. And I don’t see much risk there. What are people going to do, manipulate BTC gas price upwards thus making a stronger argument for holding XCP? Manipulate downwards to get cheap contract execution? And in either case they have to add liquidity to the BTC/XCP pair. The higher the liquidity of BTC/XCP DEx trading pair, the harder it is to manipulate.
@JPJA: Without a XCP burn ceiling built in, it’s possible for us to run out of XCP.
An integrated BTC-XCP vending machine can be a solution. The wallet automatically buys XCP (gas) with BTC when you upload the contract. On the protocol level XCP must be used, as explained earlier. On the user level, only BTC is needed. The wallet developer can even make a small exchange rate cut, so it will be a win-win-win.
Thus the solution will come from a 3rd party. The protocol must run on XCP for technical reason.
Running out of XCP can never happen.
If the fees were fixed, XCP would eventually (years down the road) be scarce and the XCP price go up as a result, which in turn would mean less usage (this is no good and should be avoided). Only a hard fork could solve the problem (ref the 1 MB block size issue).
If fees are reduced proportionally with the XCP supply, this problem is reduced somewhat but another -more important- problem remains. The price fluctuates for other reasons too. Expect the XCP price to fluctuate wildly because of speculation, DEX demand and soon smart contract lottery demand.
With the automatically adjusted gas price, as proposed, a reasonable load on servers is ensured and the dollar price of XCP is irrelevant. Even in a hypothetical situation, if all but one XCP were burned, the system would still run fine on the remaining 100,000,000 XCP-satoshis.
@JPJA you’re right about the XCP price fluctuations. Gas should be cheap, but if XCP is gas, then the price of gas is dependent on the price of a deflationary asset. Gas costs could skyrocket and this would discourage use.
We need to be fairly certain gas stays cheap, while still making gas accessible to BTC holders and giving a reason for holding or burning XCP.
Take OP’s proposed XCPC idea: give XCPC to all XCP holders through a dividend. You could also easily burn XCP or BTC for XCPC, or acquire it on the DEx. That way it would be much simpler to ensure gas stays cheap while still making Ethereum contract execution accessible to BTC holders.
I’ll probably run into some internal maximum of this forum s/w, sorry…
It depends on the price ;-). If it’s cheaper to burn XCP than running EVM on a comparable platform, it would promote the burning of XCP until such time the price advantage is gone.
We can’t freeze the XCP exchange rate, so this doesn’t do much in terms of stability and predictability of SC gas cost.
It may promote “hoarding” of XCP when the price is seen as good, but since there’s no easy way to figure out easily when to buy/sell so ultimately contract users would probably prefer something simpler.
Well this doesn’t pay for gas (execution of SCs) so it doesn’t reward all the right people.
How many servers do we need to run SC’s and how many SC’s (assuming resources required by the “average” SC) can a single server execute? Do we expect all CP servers to execute all CP contracts?
I think we can’t (shouldn’t) discuss payments before we know the costs. A clearer problem statement, substantiated with some testnet metrics, would be highly desirable, IMO.
Okay, but is everyone fine with the actual servers not getting paid at all for the execution of SCs? I can’t say I like that.
CP servers already don’t get paid and it’s somehow assumed that they are maintained by folks who “make money anyway”.
Maybe it’s not possible to do anything about this from a tech side, but I’m asking because above I asked a related question: do we expect that the most powerful CP server will be able to execute all SCs and not fall behind? If not, who’s going to tell 10 smaller nodes which contacts to pick?
This is another example why performance tests with gas-guzzling SCs should be done.
Sounds fine, except that if you deploy an SC to operate it for a while (say 1 year) you can’t know how much it’s going to cost you, so you’d have to either buy up a year supply of gas (XCP) or have dynamic pricing for your customers (would they be okay with that?).
I like your thinking, but as before I’d like to know why everyone assumes CP servers are free.
I’d like everyone (who has an opinion) to offer their estimate of resources and cost required to run a CP server that can process all SCs without falling behind.
And who burned BTC the first time around.
In real life terms, if it went deflationary, it would become too expensive to run SCs so demand for gas-related XCP would drop until such time XCP becomes cheap enough.
Other points:
Imagine the unimaginable: in 3 year’s time BTC can do 5 times as many transactions, etc. The cost of running a CP server node that can execute all SCs in near-real time becomes $500/month. What then? One server goes down, CP SCs stop executing.
Same scenario, but there’s no single x86 server that can execute all SCs
The price of XCP drops to 90% or jumps 10x so gas becomes ridiculously cheap or expensive. Noone can afford to run a server, or pay for gas, on CP.
I am also wondering why we’re not considering BTC more. Maybe a mix of sorts (say, 0.1 XCP to create a SC, and a separate charge to execute it), but this still doesn’t meet my own goal of rewarding server owners.
Sounds great as long as you’re not the one who has to pay for the server that executes SCs. It’s like when end users are complaining that bitcoin tx fees are too damn high.
Someone correct me if I’m wrong here, but does anyone think it’d be a good idea to have only 2-3 CP servers that can execute SCs? That sounds terrible to me.
POS vote is potentially dangerous.
I like the idea of dynamic parametric formula, maybe a combo that includes BTC (current hash rate, perhaps) if part of payment could be in BTC.
I need to study this (I deliberately haven’t, to be able to approach this with an open mind) but if contracts can be activated only by BTC tx that make use of it, the cost of BTC tx should be able to prevent EVM exec spam.
I share your opinion on this.
Post-BTC planning should be out of scope - it’s way beyond anyone’s capability, BTC is the core XCP technology and a hard fork would be required in any case, so why bother?
I know I’ve seen 1-2 complaints about CP burning BTC, but most people realize it increases the value of BTC for everyone and overwhelmingly there’s no bad feeling about that.
It wouldn’t tie the price of XCP to BTC, IMO. If “1 gas” costs ( 2 * bitcoin_core_recommended_tx_fee) + ( 0.0001 XCP * unit_of_work), then they can’t choose the cheapest.
Okay but that’s just 1 piece of the puzzle. In that case the price (in US$) would vary wildly so we need another piece - how to change the formula dynamically so that SC owners get a reasonable degree of predictability and be able to justify deploying their SCs on CP.
It was $0.7 and it was $7 and within months it could be something entirely different. If you have an app that has 2 SCs and consider where you want to run this, and then figure it may cost you anywhere between $170 to $1,700 per year, it’s not a fun decision to make. Even if you prefund your SC, if XCP goes up 5x, you’d spend 5x more than you planned.
Do you mean metacoin? Altcoins are currencies that don’t use the BTC blockchain.
I don’t think using a metacoin is a problem. Gas fees in XCP would make XCP more liquid and narrow the spread which would also be good for the DEx and other applications and use cases. (I think a mixed payment in BTC and XCP would be even better, but even in that scenario there’s XCP).
But it was mentioned above that the cost could drop to 0.00001 XCP or lower.
Yes, and XCP being much smaller, it’d gyrate wildly. That’s why I’m in favor of a combined BTC + XCP formula.
Why would they want to discriminate against burns?
I would like to add here to what @robby_dermody said above, that it could be dangerous to reference DEx prices.
That would be true, but only initially. As people start crawling DEx for good deals, the price should eventually become stable. I would not exclude the possibility that a stable BTCXCP market would be created on the DEx if one knew that SCs reference the price. For example, let’s assume someone sells XCP for a low price. They would be sold immediately. If someone sells XCP for a price that is 5% or more expensive than elsewhere, and SCs must buy it, many would buy elsewhere and create a slightly lower sell offer on the DEx because they could still make money this way.
There’s no need to make gas cheaper than the prevailing price for comparable work. Cost (in terms of compute resources) is roughly the same as on Ethereum (since the code is the same) and nothing is free.
Can @rubensayshi or @robby_dermody create a CP EVM benchmark suite (pick some popular contracts, add them to counterparty-lib repo?) so that we have a way to evaluate the cost in compute resources? I’d love to kick tires this way, and in the meantime I’ll start reading about how ETH does costing to prepare for part 2 of this discussion
Edit: I did some googling and put my notes in this post below. Those who are new to this problematic can check it out to save some time.
There is a lot of fascinating discussion in this thread and I feel there is a serious opportunity for innovation in this area. Here are some criteria that any accepted solution should ideally have:
Reduce the friction for using BTC to perform Counterparty Protocol operations
Deal with the issues (no matter how theoretical or long-term) associated with a perpetually dwindling XCP supply
Provide adequate incentives for Counterparty Node deployment/operation
Ruben has created a demo project to compose P2SH transactions, for testing purposes. Impressively, it also contains the basic components to demonstrate an atomic swap between BTC and XCP! This is an incredibly exciting development that will have more news forthcoming soon.
With this in place, it looks to the end user like they have used BTC when in fact they bought XCP first as a silent intermediate step. Also the DEx could be a lot more fluid when using BTC in general as a result.
Item 2 can be dealt with by a proposal that I have not seen mentioned yet - buy back previously burned XCP with BTC. The maximum amount of XCP ever in circulation was 2649791.07838225 XCP. At the time of writing it is 2,626,671.08. Currently this will only go down (e.g. as assets are created, and potentially as smart contracts are fueled, etc.). But what if you could buy these back as an instant BTC transaction. The supply of XCP wouldn’t reach (or at least wouldn’t be stuck at) 0 in that case. These trades could be made at the market rate (read from the DEx, for example). The original supply of XCP (2,626,671.08) would not be exceeded.
EXAMPLE
Suppose there are 2,600,000.0 XCP in circulation. I have 1.0 BTC and I want to add it as gas to a smart contract. The market rate according to the DEx is 1 BTC = 5 XCP. In just one Counterparty Protocol operation I send the BTC to a proveably unspendable address (e.g. 1CounterpartyXXXXXXXXXXXXXXXUWLpVr) and the protocol loads the smart contract with 5 XCP … AND the total XCP in circulation now reads 2,600,005.0. This would return to 2,600,000.0 as the smart contract executes over time.
This type of control mechanism would likely lead to a situation where almost the same number of XCP as there were originally are always in circulation. XCP essentially would neither be inflationary nor deflationary in that case. Funnily enough, this mechanism flips things from burning XCP to actually burning BTC (to get newly issued “replacement” XCP)!
Further detail: if you divide the supply of Bitcoin (15654475.0, at the time of writing) by the maximum supply of XCP (2649791.07838225) to get a value of approx. 5.907815. You could normalize this by dividing by the 5.907815, giving a 1:1 ratio between XCP price and BTC price. Call this the Normalized Supply Ratio. With the max supply of XCP almost fixed this ratio would scale dynamically with the (currently inflating) supply of Bitcoin. This ratio could serve as a way of fixing an upper limit on the price of XCP. In the previous example, instead of buying back XCP at the market price, you could buy it back at the Normalized Supply Ratio Price. At the time of writing the Market Ratio would be 318.47134.
The gas cost could be set directly in BTC then (which is good because it is more liquid than XCP, at least for now). Say it is set to 0.001 BTC or 1 mBTC. At most (at the Normalized Supply Ratio Price) this would also cost 0.001 XCP. Or at the Market Ratio Price it would only cost 0.000000314 XCP, at the time of writing. The large difference in price is actually useful. The buy-back mechanism route is prohibitively expensive so it is a deterrent to it being used for large trades in the short term. But it is also instantaneous so you are paying for the convenience. You could wait for a bargain by just trading for XCP though this is less convenient. This is somewhat analogous to the miners fee’s mechanism in BTC - you can pay a decent fee now to effectively guarantee that your transaction is included in the next block. Or you can pay little or no fee and wait for a potentially long time to be included in a block.
Please consider the implications of all of this: The ability to use BTC quickly and easily and (practically) directly to fuel smart contracts directly in the Bitcoin Blockchain would be incredible.
What if gas go after that have been used to wind tunnel smart contract machine and then machine throw XCP’s back to DEX with little higher price than what it was last time and same time when have used more gas new contracts need little bit lower amount fuel? Then gas can’t finish and we have enough gas for mooon.
I will share my humble opinion on the matter as well
First of all, I am actually against using XCP as gas and diminish the total supply at least initially. My concerns for doing so are
1 Conflict of interest
Current XCP holders(most of people posting here including myself) of course wold welcome the diminishing supply of XCP as it will likely increase the price per XCP. But this may in the future prevent new people from joining the network and create an unfair environment for late comers.
2 Lack of data about the gas model
That being said, I am not against consuming XCP as gas in the future. But my biggest concern is it is hard (or maybe impossible) to come up with an algorithm that somehow strikes a good balance between the fairness for everyone mentioned above, sustainable supply, price stability, optimal gas cost adjustment and spam protection. I think we need more data(usage, burdens on full nodes etc) before burning the supply without careful consideration.
3 Lack of incentives to run a full node
Basically what Sean suggested. Right now, there are practically no incentives to run full Counterparty nodes except for good will and possibly use it for their own businesses. Spam protection with gas is important but I think the lack of incentive to run a full node is also a big issue especially there is no mining for CP. If we can come up with a way to reward nodes by redistributing XCP fuels without creating different attack vectors, that would be nice(I don’t know if it’s technically possible at all but I’d just state it anyways)
I am just against rushing things and come up with a half-baked burning algorithm and don’t want us to diminish the XCP supply. I believe this stuff needs more discussion and data and don’t think we can “solve” this in a month or two. Thus I am against burning XCP as gas at least initially and start from a less drastic approach and then eventually find the right balance and move to the “burn” model in the long run.
Proof of Work is kinda the (only) solution to fairly rewarding node operators, afaik, I don’t think we can come up with a good solution to this idea and if we could it would probably on it’s own take as much work / effort to build as the EVM implementation.
So I think that direction is out of our reach.
Indirectly burning XCP should reward holders, which are also most likely users / node operators.
I don’t think we per-see need a lot of nodes, even if you’re the only running node Counterparty will continue to function the same as when there would be 10k nodes running,… we only need the bitcoin network to be decentralized enough.
I agree there’s a conflict of interest here, but also don’t know how to work around it.
I think many (early) buyers of XCP feel that them buying into XCP (early) was a way of vouching / supporting Counterparty (eventhough it didn’t directly do anything for Counterparty other than create value for the token).
So that’s why they probably also feel that it’s only fair the EVM would burn XCP and as a result give them a return on their (early) investment.
I think on paper the XCP price should settle on what running a smart contract should cost (in BTC / dollar value) and take into account the decay, but in practice …
Burning XCP will surely reward XCP holders but that does not necessarily lead to them to run full nodes though.(There is no point doing that for most XCP holders)
I also understand that even with 1 node, the protocol functions technically but that will create a necessity for trusting the node operator, correct? So technically it’s not a problem but as a decentralized protocol it may put a question mark on Counterparty if there are only a few full node operators in my opinion.
I don’t really have a problem with burning XCP and rewarding the early investors and supporters, it’s just the rate of burning and a possible gas cost calculation algo I am still a bit uneasy about. It’s really hard to agree on what is fair for everyone for the mid to long term without overcompensating the early adopters who dominate the discussion anyways. If we mess it up, it may turn into a huge obstacle attracting new devs and users.
How’s your discussion with econ experts going btw? any progress or feedback you can share with us?
it largely depends on what you are using Counterparty for, if it’s for something that only involves a limited set of assets changing hands between machines / apps (or in the future smart contracts) then you could very well continue using it even if your application is the last application using it and there are very few nodes.
hell, you could also not upgrade and/or fork and as long as every party using your application is on the same version as you, that would be fine too.
this would at all times remain as decentralized and secure as when there’s thousands of nodes running (your version).
because our decentralization / security comes from the bitcoin blockchain, not the counterparty nodes.
the only problem would be once one of the parties using your application wants to take some of the tokens outside of it, it might not have consensus with other nodes such as an exchange.
but as long as the tokens stay within the group of users that all run the same version of Counterparty there won’t be any problem.
so I don’t think we need an incentive to get more nodes running, hell, we don’t even have any way of counting nodes (robby is playing with some ideas to get nodes to share anonymous stats though so we someday can).
we want people to use Counterparty (both mainnet and testnet) and as a result they’d be running a node, because trusting a node which exposes their API publicly for more than a bit of testing, that would be centralization (coindaddy offers one of these).
As for the formula, I’m poking the econ professor right now, but I fear he’s been busy, if that’s the case I’m gonna ask him to forward the question to maybe a few of his students who might be interested, I wrote a document explaining the problem and giving as much info as possible for a non-bitcoiner to understand it.
I had a short chat with Vitalik and he essentially said something similar to you (paraphrasing); it’s too early to say anything meaningful about the ‘right’ gas price and that we should just take the ‘dumb aproach’ and aim for “~$0.1 USD per million gas”.
Not sure if its technically feasible, but some sort of node reward along with a burn of XCP would be nice to see. Nodes “mining” smart contracts could perhaps keep half of the XCP that was to be burned.
