[quote author=Bountyful link=topic=150.msg1041#msg1041 date=1393796187]
[quote author=JahPowerBit link=topic=150.msg1023#msg1023 date=1393785790]
[quote author=ginko-B link=topic=150.msg1019#msg1019 date=1393784440]
2 - all fees paid into the bounties
[/quote]
IMHO is not a good idea. Developments must be funded by donations from the community and those who develop successful business with XCP. Using fees for bounties adds a notion of authority and thus centralization.
[/quote]
Well, there’s a free-rider problem that funding with donations doesn’t solve: Donations are voluntary so most people will not give a donation to cover the true cost of improving the protocol. Being a free rider is cheaper than putting up funds for development.
[/quote]
Be patient and wait Counterparty is best known. Will there be more and more developers and donations. Of course the vast majority of people do not make donations (I can testify;-)) but like everywhere it is the few who make big donations that makes the difference (Pareto principle).
[quote author=Bountyful link=topic=150.msg1041#msg1041 date=1393796187]
Secondly, the bounties are already handled by the devs and it is centralized as of today so I’m not sure we can avoid centralization. Like you, I aspire to pure decentralization which is why i say this is a bridge to building a self-sustaining funding system inside the protocol or a Decentralized Autonomous Protocol. I would like to know that the system can fund itself given that the burn period is over and there is no further way to create more XCPs. I would also like to find a way to make sure that my fees for asset issuance can benefit the protocol vs. just going to burning which is unattractive for the various reasons I listed above.
[/quote]
The bounties are handled by the devs because they are the main donators (the few who make the difference). If you have enough BTC/XCP, you can organize your own centralized bounty. I think the reason for this confusion is that the PhantomPhreak team has three roles:
- Inventors of the protocol (Counterparty)
- Developers of client reference (counterpartyd)
- Major donators (bounties)
This may give an impression of centralization, but it is not. I am convinced that in the future these three roles will no longer be provided by the same people.
[quote author=Bountyful link=topic=150.msg1041#msg1041 date=1393796187]
If collecting fees for the protocol is not attractive because it centralizes authority and is too onerous to put into the protocol, then let’s reduce the XCP burning fee to something much lower than 5XCP?
[/quote]
If I understand this is temporary: https://bitcointalk.org/index.php?topic=395761.msg5464856#msg5464856
Burning BTC or XCP is a no-no because eventually this raises the price of asset issuance to insane levels, but anything centralized like bounties or relying on dollar-price oracles is also out if we want Counterparty to be a fully decentralized system.
What is the purpose of the fee in the first place? Spam prevention? Assuming assets are issued via a Bitcoin tx, perhaps force the byte size to be large enough to require a larger miner’s fee. Miners are the logical place to look because they are the ones ultimately doing the work. They are the only ones who can provide a solution that is both market-based and decentralized.
Barring that, some kind of lottery where the XCP go to a random holder (greater odds for addresses with larger XCP holdings, a kind of stake-based system) might work, assuming most XCP are not lost (which would result in many XCP being effectively burnt as they are sent to addresses with lost private keys).
[quote author=Zangelbert Bingledack link=topic=150.msg1056#msg1056 date=1393822021]
Burning BTC or XCP is a no-no because eventually this raises the price of asset issuance to insane levels, but anything centralized like bounties or relying on dollar-price oracles is also out if we want Counterparty to be a fully decentralized system.
What is the purpose of the fee in the first place? Spam prevention? Assuming assets are issued via a Bitcoin tx, perhaps force the byte size to be large enough to require a larger miner’s fee. Miners are the logical place to look because they are the ones ultimately doing the work. They are the only ones who can provide a solution that is both market-based and decentralized.
Barring that, some kind of lottery where the XCP go to a random holder (greater odds for addresses with larger XCP holdings, a kind of stake-based system) might work, assuming most XCP are not lost (which would result in many XCP being effectively burnt as they are sent to addresses with lost private keys).
[/quote]
How would we decide the size of the miner’s fee then? I think the problem is determining how this fee is priced to reduce spam. If we could have assets be subscribed with a maintenance fee to the miners, then this could possibly be a solution as it would be decentralized and would not require any bounty-determination work or lottery system.
[quote author=Zangelbert Bingledack link=topic=150.msg1056#msg1056 date=1393822021]
Burning BTC or XCP is a no-no because eventually this raises the price of asset issuance to insane levels, but anything centralized like bounties or relying on dollar-price oracles is also out if we want Counterparty to be a fully decentralized system.
What is the purpose of the fee in the first place? Spam prevention? Assuming assets are issued via a Bitcoin tx, perhaps force the byte size to be large enough to require a larger miner’s fee. Miners are the logical place to look because they are the ones ultimately doing the work. They are the only ones who can provide a solution that is both market-based and decentralized.
Barring that, some kind of lottery where the XCP go to a random holder (greater odds for addresses with larger XCP holdings, a kind of stake-based system) might work, assuming most XCP are not lost (which would result in many XCP being effectively burnt as they are sent to addresses with lost private keys).
[/quote]
The problem with giving the asset issuance fee to miners is the same as the problem with giving BTC trade fees to miners: the miners can game the system. Admittedly, there is less motivation to game asset issuances than the order book, but it’s still, conceptually, a problem, and indeed may be a real problem as time goes on.
[quote author=cityglut link=topic=150.msg1059#msg1059 date=1393854735]
[quote author=Zangelbert Bingledack link=topic=150.msg1056#msg1056 date=1393822021]
Burning BTC or XCP is a no-no because eventually this raises the price of asset issuance to insane levels, but anything centralized like bounties or relying on dollar-price oracles is also out if we want Counterparty to be a fully decentralized system.
What is the purpose of the fee in the first place? Spam prevention? Assuming assets are issued via a Bitcoin tx, perhaps force the byte size to be large enough to require a larger miner’s fee. Miners are the logical place to look because they are the ones ultimately doing the work. They are the only ones who can provide a solution that is both market-based and decentralized.
Barring that, some kind of lottery where the XCP go to a random holder (greater odds for addresses with larger XCP holdings, a kind of stake-based system) might work, assuming most XCP are not lost (which would result in many XCP being effectively burnt as they are sent to addresses with lost private keys).
[/quote]
The problem with giving the asset issuance fee to miners is the same as the problem with giving BTC trade fees to miners: the miners can game the system. Admittedly, there is less motivation to game asset issuances than the order book, but it’s still, conceptually, a problem, and indeed may be a real problem as time goes on.
[/quote]
Agreed. The miners can game the system to funnel BTC fees to themselves and as asset issuance increase, so would the incentive.
How about an interim and direct solution: We simply reduce the XCP from 5 XCP to 2XCP for asset issuance?
We can observer whether SPAM asset issuance increases with this reduction in a brief period of time and see how it impacts the ecosystem.
Thoughts?
[quote author=kdrop20 link=topic=150.msg1040#msg1040 date=1393796066]
[quote author=ginko-B link=topic=150.msg1029#msg1029 date=1393789064]
[quote author=JahPowerBit link=topic=150.msg1023#msg1023 date=1393785790]
[quote author=ginko-B link=topic=150.msg1019#msg1019 date=1393784440]
2 - all fees paid into the bounties
[/quote]
IMHO is not a good idea. Developments must be funded by donations from the community and those who develop successful business with XCP. Using fees for bounties adds a notion of authority and thus centralization.
[/quote]
But what if the bounties are community-generated and community-ranked, like Bountyful was proposing? (And I understand that building such a system is a huge amount of work… sigh)
[/quote]
I like this proposal, we desperately needs funds for security and development related bounties.
[/quote]
Agreed on both parts
How about we make it even simpler by using a formula like this:
issuance fee = (N * 365)/(N + 2016)
where N = number of valid issuances from the previous 2016 blocks
N FEE
===================
0 0
1 0.180961824
2 0.361744301
3 0.542347697
4 0.722772277
5 0.903018308
6 1.083086053
7 1.262975779
8 1.442687747
9 1.622222222
10 1.801579467
11 1.980759743
12 2.159763314
13 2.338590439
14 2.517241379
15 2.695716396
16 2.874015748
17 3.052139695
18 3.230088496
19 3.407862408
20 3.58546169
21 3.762886598
22 3.94013739
23 4.117214321
24 4.294117647
25 4.470847624
26 4.647404505
27 4.823788546
28 5
29 5.17603912
30 5.351906158
31 5.527601368
32 5.703125
[quote author=GLaDOS link=topic=150.msg1065#msg1065 date=1393880459]
How about we make it even simpler by using a formula like this:
issuance fee = (N * 365)/(N + 2016)
where N = number of valid issuances from the previous 2016 blocks
N FEE
===================
0 0
1 0.180961824
2 0.361744301
3 0.542347697
4 0.722772277
5 0.903018308
6 1.083086053
7 1.262975779
8 1.442687747
9 1.622222222
10 1.801579467
11 1.980759743
12 2.159763314
13 2.338590439
14 2.517241379
15 2.695716396
16 2.874015748
17 3.052139695
18 3.230088496
19 3.407862408
20 3.58546169
21 3.762886598
22 3.94013739
23 4.117214321
24 4.294117647
25 4.470847624
26 4.647404505
27 4.823788546
28 5
29 5.17603912
30 5.351906158
31 5.527601368
32 5.703125
[/quote]
Interesting and very intriguing, but I’m not sure what problem is this formula solving. The Fee keeps going up indefinitely. Yes?
Reading this approach, it seems that at some point it becomes impractical to continue issuing assets on Counterparty if the fees require burning XCP at ever increasing rates.
No, I think it’s some sort of moving average. Pretty clever actually. I wasn’t expecting less from GLaDOS !
[quote author=NotSure link=topic=150.msg1067#msg1067 date=1393883076]
No, I think it’s some sort of moving average. Pretty clever actually. I wasn’t expecting less from GLaDOS !
[/quote]
Thanks NotSure! I will look and read again! I know GLaDOS has skills and I need to read some more.
[quote author=Bountyful link=topic=150.msg1066#msg1066 date=1393881340]
[quote author=GLaDOS link=topic=150.msg1065#msg1065 date=1393880459]
How about we make it even simpler by using a formula like this:
issuance fee = (N * 365)/(N + 2016)
where N = number of valid issuances from the previous 2016 blocks
N FEE
===================
0 0
1 0.180961824
2 0.361744301
3 0.542347697
4 0.722772277
5 0.903018308
6 1.083086053
7 1.262975779
8 1.442687747
9 1.622222222
10 1.801579467
11 1.980759743
12 2.159763314
13 2.338590439
14 2.517241379
15 2.695716396
16 2.874015748
17 3.052139695
18 3.230088496
19 3.407862408
20 3.58546169
21 3.762886598
22 3.94013739
23 4.117214321
24 4.294117647
25 4.470847624
26 4.647404505
27 4.823788546
28 5
29 5.17603912
30 5.351906158
31 5.527601368
32 5.703125
[/quote]
Interesting and very intriguing, but I’m not sure what problem is this formula solving. The Fee keeps going up indefinitely. Yes?
Reading this approach, it seems that at some point it becomes impractical to continue issuing assets on Counterparty if the fees require burning XCP at ever increasing rates.
[/quote]
Thanks GLaDOS. This is a very interesting approach.
However, my objection still holds in spite of my admiration.
If issuances increase, the issuer is still penalized with burning more XCP as business succeeds and more issuances are required. This still makes it hard to scale successful asset businesses on Counterparty and the lost XCP is not recoverable.
Do you have any thoughts on how we can limit the downside of your approach?
I thought I’d pitch in an idea. It would involve quite a code change but I think it has utility and does to some extent address the anti-spam idea.
1) Assets should be issued in a domain style hierarchy where subdomains cost less
examples:
MYCOMPANY might cost 5 XCP
MYCOMPANY.VENTUREA might cost 2.5 XCP
MYCOMPANY.VENTUREA.PRODUCT might cost 1.25 XCP
2) The hierarchy will then be useful to remove top level assets from loading up the market.
3) The hierarchy is then useful if someone wants to use the assets as a way of selling virtual assets like in a game. Imagine RPGGAME1.SHORTSWORD being traded on the DEX for RPGGAME2.DAGGER
[quote author=cityglut link=topic=150.msg1059#msg1059 date=1393854735]
The problem with giving the asset issuance fee to miners is the same as the problem with giving BTC trade fees to miners: the miners can game the system. Admittedly, there is less motivation to game asset issuances than the order book, but it’s still, conceptually, a problem, and indeed may be a real problem as time goes on.
[/quote]
Can you explain how they can game the system? If you mean something like price fixing, that doesn’t actually work because the incentive to break the price fixing agreement by undercutting the competition with lower fees becomes too great (same logic as to why Bitcoin tx fees can’t be gamed by price fixing). If the issue is blockchain spam them the solution pretty much has to rely on miners as they’re the ones bearing the increased costs, but if the issue is that the asset register will be too huge and unwieldy to read with everyone trying to name their asset AAAAACME to get at the top of the list then perhaps some kind of value (market cap) ranking would work. Maybe even a timed cutoff for the lowest valued assets to be dropped from the register.
[quote author=Bountyful link=topic=150.msg1069#msg1069 date=1393892595]
If issuances increase, the issuer is still penalized with burning more XCP as business succeeds and more issuances are required. This still makes it hard to scale successful asset businesses on Counterparty and the lost XCP is not recoverable.
Do you have any thoughts on how we can limit the downside of your approach?
[/quote]
Ignoring code changes for now, I would combine the simple formula with Global_trade_repo’s hierarchy idea. If only there’s a way to recover the XCP so nothing is lost…
[quote author=Global_trade_repo link=topic=150.msg1073#msg1073 date=1393902111]
I thought I’d pitch in an idea. It would involve quite a code change but I think it has utility and does to some extent address the anti-spam idea.
1) Assets should be issued in a domain style hierarchy where subdomains cost less
examples:
MYCOMPANY might cost 5 XCP
MYCOMPANY.VENTUREA might cost 2.5 XCP
MYCOMPANY.VENTUREA.PRODUCT might cost 1.25 XCP
2) The hierarchy will then be useful to remove top level assets from loading up the market.
3) The hierarchy is then useful if someone wants to use the assets as a way of selling virtual assets like in a game. Imagine RPGGAME1.SHORTSWORD being traded on the DEX for RPGGAME2.DAGGER
[/quote]
This is a really good idea. I believe many of us would come to the same conclusion if we give some thoughts to Bountyful’s problem of 1000 assets.
My thinking was that these sub-assets should be free once the primary asset had been created. We could keep it simple by limiting the level to just one dot.
[quote author=GLaDOS link=topic=150.msg1077#msg1077 date=1393916772]
[quote author=Bountyful link=topic=150.msg1069#msg1069 date=1393892595]
If issuances increase, the issuer is still penalized with burning more XCP as business succeeds and more issuances are required. This still makes it hard to scale successful asset businesses on Counterparty and the lost XCP is not recoverable.
Do you have any thoughts on how we can limit the downside of your approach?
[/quote]
Ignoring code changes for now, I would combine the simple formula with Global_trade_repo’s hierarchy idea. If only there’s a way to recover the XCP so nothing is lost…
[quote author=Global_trade_repo link=topic=150.msg1073#msg1073 date=1393902111]
I thought I’d pitch in an idea. It would involve quite a code change but I think it has utility and does to some extent address the anti-spam idea.
1) Assets should be issued in a domain style hierarchy where subdomains cost less
examples:
MYCOMPANY might cost 5 XCP
MYCOMPANY.VENTUREA might cost 2.5 XCP
MYCOMPANY.VENTUREA.PRODUCT might cost 1.25 XCP
2) The hierarchy will then be useful to remove top level assets from loading up the market.
3) The hierarchy is then useful if someone wants to use the assets as a way of selling virtual assets like in a game. Imagine RPGGAME1.SHORTSWORD being traded on the DEX for RPGGAME2.DAGGER
[/quote]
This is a really good idea. I believe many of us would come to the same conclusion if we give some thoughts to Bountyful’s problem of 1000 assets.
My thinking was that these sub-assets should be free once the primary asset had been created. We could keep it simple by limiting the level to just one dot.
[/quote]
Thank you for the further explanation GLaDOS. This would actually work nicely for us as well given your elaboration above. Yes.
For example, we are looking to issue assets by Gold Issuer and the current system is extremely limiting. Have this hierarchy allows us to gain more granular control of our asset inventory
GOLD.PPM.AAAISSUE
etc…
etc…
GOLD.APM.AABISSUE
etc…
etc…
DIAMOND.NAS.AAISSUE
This would also make it less rewarding to try to horde names as the subdomain namespace is larger.
If we could keep the issuance process for these subdomains free, I think we can definitely build something scalable here as we can build the business out without worrying about asset issuance costs or squatters incentivized to hold names hostage.
I still think that a proof of stake voting mechanism is the best way to pick the fee—it’s the most general. And the 5 XCP is really just a stop gap. It’s important, however, not to change it too often. For that reason, if it were to be lowered right now, I think that 0.5 XCP, or ever lower, would be a better option than 2 XCP. Of course, it’s hard to predict what the price of XCP will be even a short time in the future.
[quote author=PhantomPhreak link=topic=150.msg1079#msg1079 date=1393936545]
I still think that a proof of stake voting mechanism is the best way to pick the fee—it’s the most general. And the 5 XCP is really just a stop gap. It’s important, however, not to change it too often. For that reason, if it were to be lowered right now, I think that 0.5 XCP, or ever lower, would be a better option than 2 XCP. Of course, it’s hard to predict what the price of XCP will be even a short time in the future.
[/quote]
Agreed on all points shared above.
Proof of Stake voting for the fee selection sounds a great way to determine price. Does this mean fees go back to XCP holders by stake size as well?
A much lower fee is most welcome as an immediate change and yes much lower than 0.5 XCP would continue to reduce the cost of business. Anything to lessen the immediate pain/expense to build on the platform.
Global_trade_repo idea is also a good way to reduce SPAM issuance by folks hoarding onto names. I am not sure how much code is required, but have you considered his option as well?
[quote author=Global_trade_repo link=topic=150.msg1073#msg1073 date=1393902111]
I thought I’d pitch in an idea. It would involve quite a code change but I think it has utility and does to some extent address the anti-spam idea.
1) Assets should be issued in a domain style hierarchy where subdomains cost less
examples:
MYCOMPANY might cost 5 XCP
MYCOMPANY.VENTUREA might cost 2.5 XCP
MYCOMPANY.VENTUREA.PRODUCT might cost 1.25 XCP
2) The hierarchy will then be useful to remove top level assets from loading up the market.
3) The hierarchy is then useful if someone wants to use the assets as a way of selling virtual assets like in a game. Imagine RPGGAME1.SHORTSWORD being traded on the DEX for RPGGAME2.DAGGER
[/quote]
This sounds like a good idea to me.It will help the system scale, without encouraging squatters.
[quote author=Global_trade_repo link=topic=150.msg1073#msg1073 date=1393902111]
I thought I’d pitch in an idea. It would involve quite a code change but I think it has utility and does to some extent address the anti-spam idea.
1) Assets should be issued in a domain style hierarchy where subdomains cost less
examples:
MYCOMPANY might cost 5 XCP
MYCOMPANY.VENTUREA might cost 2.5 XCP
MYCOMPANY.VENTUREA.PRODUCT might cost 1.25 XCP
2) The hierarchy will then be useful to remove top level assets from loading up the market.
3) The hierarchy is then useful if someone wants to use the assets as a way of selling virtual assets like in a game. Imagine RPGGAME1.SHORTSWORD being traded on the DEX for RPGGAME2.DAGGER
[/quote]
+1
[quote author=PhantomPhreak link=topic=150.msg1079#msg1079 date=1393936545]
I still think that a proof of stake voting mechanism is the best way to pick the fee—it’s the most general. And the 5 XCP is really just a stop gap. It’s important, however, not to change it too often. For that reason, if it were to be lowered right now, I think that 0.5 XCP, or ever lower, would be a better option than 2 XCP. Of course, it’s hard to predict what the price of XCP will be even a short time in the future.
[/quote]
Ok how about we make the formula just a bit more complicated:
issuance fee = (N * V)/(N + 2016) where V=365 to start.
N = number of valid issuances from the previous 2016 blocks
V = running total of votes that can be anywhere from 0 to 2016 to keep it simple
Then whoever issues an asset gets to vote 0, -1, or +1 to V.
Here’s what the fee would be like for V=1.
N FEE
===================
0 0
1 0.000495786
2 0.00099108
3 0.001485884
4 0.001980198
5 0.002474023
6 0.002967359
7 0.003460208
8 0.003952569
9 0.004444444
10 0.004935834
and for V=2016
N FEE
===================
0 0
1 0.999504214
2 1.998017839
3 2.995542348
4 3.992079208
5 4.987629886
6 5.982195846
7 6.975778547
8 7.968379447
9 8.96
10 9.950641658
Asset issuance will always be free regardless of the votes…everyone just needs to coordinate for 2016 blocks.