BitShares Forum
Main => General Discussion => Topic started by: puppies on January 02, 2016, 08:20:25 pm
-
There has been a lot of discussion about improving liquidity recently. I wanted to get some input on possible actions the committee account could take.
Option 1. The committee could sell the bitassets collected by the fee pool back into the market.
Through the fee pool the committee is currently long 6910 USD, 7860 CNY, and .473BTC. In the case of USD that is over 6% of total supply.
Option 2. The committee could use the bts procured from selling the assets in option 1 to short more of the asset into existence. Assuming a 3x collateral ratio, the committee could short an extra 2300USD into existence.
Option 3. The committee could receive funds from a worker proposal, and use those to short a larger amount of an asset into existence. We could for example create 50k USD, and 50 BTC.
This is not an endorsement of any of these actions. I am trying to collect community input.
-
In my understanding the BitAssets in the fee pool must be sold regularly, and the proceeds must be used to re-fill the fee pool with BTS to enable transfers of BitAssets without owning BTS.
Despite the slight advantage from the CER, this buying/selling of BitAssets is not necessarily profitable. In order to maintain the fee pool reserves it is IMO not an option to use them for anything else.
-
Assuming MAKER will incentivize market making on the DEX by the end of Q1, what would be the best way to use those funds to incentivize market making services on external exchanges?
BitUSD has recently been added to Poloniex, which is often 1st/2nd for BTS volume. It is also where NBT finds most of it's demand so I would perhaps look to pay/subsidize a BitUSD market maker there.
-
I would like to go a different route with these funds, but it would take quite a bit of development. I suggest we use the funds in the fee pool to create an autonomous market maker. The price feeds published by delegates can be used and set the peg X% from the median price for each Smartcoin. Over time as fee pool grows, liquidity provided by the autonomous market maker will grow along with it. Slowly and permanently growing liquidity is better than putting a "band aid" on the problem (which is IMO what the OP does.) The autonomous market maker should only makes trades if a trade is profitable, so the fee pool grows slowly overtime from trading profits and also Smartcoin fee collection.
-
Glad to see this poll.
I meant to vote for number 3 but voted 2 by mistake.
At what price would the committee sell these bitassets though? 5% over feed price would be good
-
I would like to go a different route with these funds, but it would take quite a bit of development. I suggest we use the funds in the fee pool to create an autonomous market maker. The price feeds published by delegates can be used and set the peg X% from the median price for each Smartcoin. Over time as fee pool grows, liquidity provided by the autonomous market maker will grow along with it. Slowly and permanently growing liquidity is better than putting a "band aid" on the problem (which is IMO what the OP does.) The autonomous market maker should only makes trades if a trade is profitable, so the fee pool grows slowly overtime from trading profits and also Smartcoin fee collection.
You can't guarantee trades will be profitable, but I like the idea.
In addition, if anyone could fund this pool, and take the chance on its profitability, it could be very popular.
I think the idea of a simple native MM is a good idea in itself. Maybe a fit for a smart contract. It probably wouldn't require committee funds but may be a nice addition. And if profitable, is a nice addition to the committee account as well.
The MM pool could simply issue a token for donations to it, and the token could be exchanged back in for the equivalent percentage ownership of whats left of the pool... minus some fee.
Pretty simple.
-
I would like to go a different route with these funds, but it would take quite a bit of development. I suggest we use the funds in the fee pool to create an autonomous market maker. The price feeds published by delegates can be used and set the peg X% from the median price for each Smartcoin. Over time as fee pool grows, liquidity provided by the autonomous market maker will grow along with it. Slowly and permanently growing liquidity is better than putting a "band aid" on the problem (which is IMO what the OP does.) The autonomous market maker should only makes trades if a trade is profitable, so the fee pool grows slowly overtime from trading profits and also Smartcoin fee collection.
I'd like to see something like this too.
Apparently it's a little bit harder than just setting at X%...
The problem with market making is its only profitable in mean reverting markets (sometimes referred to as ranging), as soon as you get a strong trend the market maker will lose money because it will end up with an unbalanced inventory of assets. That risk makes designing a good one very very complicated.
I still think we should attempt to come up with something, even if it has a daily limit/other.
With more liquidity, BitUSD would be a more trusted option than NBT/Uphold but without it, it's the least favoured option so I'm always in favour of addressing this even if there's a cost and the market maker isn't profitable.
-
In my understanding the BitAssets in the fee pool must be sold regularly, and the proceeds must be used to re-fill the fee pool with BTS to enable transfers of BitAssets without owning BTS.
Despite the slight advantage from the CER, this buying/selling of BitAssets is not necessarily profitable. In order to maintain the fee pool reserves it is IMO not an option to use them for anything else.
Option 2 presupposes that we would fund the fee pools with a worker as we have done in the past. I am personally for option 1 and then using those funds to refill the fee pools.
I would like to go a different route with these funds, but it would take quite a bit of development. I suggest we use the funds in the fee pool to create an autonomous market maker. The price feeds published by delegates can be used and set the peg X% from the median price for each Smartcoin. Over time as fee pool grows, liquidity provided by the autonomous market maker will grow along with it. Slowly and permanently growing liquidity is better than putting a "band aid" on the problem (which is IMO what the OP does.) The autonomous market maker should only makes trades if a trade is profitable, so the fee pool grows slowly overtime from trading profits and also Smartcoin fee collection.
We seem to be bottlenecked by development. Either cost or manpower. If we can come up with solutions that don't require cnx, we will be all the stronger for it.
Assuming MAKER will incentivize market making on the DEX by the end of Q1, what would be the best way to use those funds to incentivize market making services on external exchanges?
BitUSD has recently been added to Poloniex, which is often 1st/2nd for BTS volume. It is also where NBT finds most of it's demand so I would perhaps look to pay/subsidize a BitUSD market maker there.
I think that increasing the amount of bitusd in circulation would help external liquidity as well. I think a worker proposal to pay someone to put up buy and sell walls on polo is definitely worth exploring. I'm sure some of our bot makers could easily design a bot that would hold the peg.
Glad to see this poll.
I voted for number 2.
At what price would the committee sell these bitassets though? 5% over feed price would be good
I think 5-10% would be the place to start.
Thanks for the input everyone.
-
I think that increasing the amount of bitusd in circulation would help external liquidity as well. I think a worker proposal to pay someone to put up buy and sell walls on polo is definitely worth exploring. I'm sure some of our bot makers could easily design a bot that would hold the peg.
And we could all help with that https://bitsharestalk.org/index.php/topic,20859.0.html
-
I'm glad that a few people like the idea of having an autonomous market maker! @Xeldal @Empirical1.2 @puppies @Akado
You can't guarantee trades will be profitable, but I like the idea.
Ah, OK my bad.. I honestly don't know a whole lot about market making, in that case this probably shouldn't be fee pool funded.
In addition, if anyone could fund this pool, and take the chance on its profitability, it could be very popular.
I agree, it is a good idea for this to be fund-able by shareholders. This would also help with the issue @Empirical1.2 brought up by allowing people to deposit assets the autonomous market maker was low on:
Apparently it's a little bit harder than just setting at X%...
The problem with market making is its only profitable in mean reverting markets (sometimes referred to as ranging), as soon as you get a strong trend the market maker will lose money because it will end up with an unbalanced inventory of assets. That risk makes designing a good one very very complicated.
I think the idea of a simple native MM is a good idea in itself. Maybe a fit for a smart contract.
I would prefer it to be autonomous or I personally would not likely deposit into it.
It probably wouldn't require committee funds but may be a nice addition. And if profitable, is a nice addition to the committee account as well. The MM pool could simply issue a token for donations to it, and the token could be exchanged back in for the equivalent percentage ownership of whats left of the pool... minus some fee.
Pretty simple.
Agreed, this could be like a UIA, or there could be a specific MM account that people can load with different Smartcoins.
I'd like to see something like this too. I still think we should attempt to come up with something, even if it has a daily limit/other. With more liquidity, BitUSD would be a more trusted option than NBT/Uphold but without it, it's the least favoured option so I'm always in favour of addressing this even if there's a cost and the market maker isn't profitable.
I concur
We seem to be bottlenecked by development. Either cost or manpower. If we can come up with solutions that don't require cnx, we will be all the stronger for it.
Unfortunately, I agree but this could at the very least be put into the long term plans for Bitshares. I think increasing liquidity should be the main priority of development.
And we could all help with that https://bitsharestalk.org/index.php/topic,20859.0.html
I can't build an autonomous decentralized MM bot, but I can attempt to build a bot that anyone could download and run on their computer. I will mess around with it... I have been learning Javascript/Node the past few months (I've been making Meteor apps specifically) and might be able to do that. I also have done some Java/C++/HTML/CSS in the past, but am really rusty in Java/C++. I think an open sourced Meteor app that anyone can download and run in their browser would be legit. I would need to study the economics of MM bots though first. ???
-
I can't build an autonomous decentralized MM bot, but I can attempt to build a bot that anyone could download and run on their computer. I will mess around with it... I have been learning Javascript/Node the past few months (I've been making Meteor apps specifically) and might be able to do that. I also have done some Java/C++/HTML/CSS in the past, but am really rusty in Java/C++. I think an open sourced Meteor app that anyone can download and run in their browser would be legit. I would need to study the economics of MM bots though first. ???
If your market maker bot could provably provide evidence of market making activity it could be used to help provide payment to those willing to provide liquidity.
-
And we could all help with that https://bitsharestalk.org/index.php/topic,20859.0.html
I can't build an autonomous decentralized MM bot, but I can attempt to build a bot that anyone could download and run on their computer. I will mess around with it... I have been learning Javascript/Node the past few months (I've been making Meteor apps specifically) and might be able to do that. I also have done some Java/C++/HTML/CSS in the past, but am really rusty in Java/C++. I think an open sourced Meteor app that anyone can download and run in their browser would be legit. I would need to study the economics of MM bots though first. ???
No need to have a decentralized one or run one. Just have people donating some funds to whoever is using bots, have them focus on USD/BTS pair and it's a go. Then when that market has a decent amount of liquidity and grows, slowly move on to other markets like CNY/BTS or BTC/BTS
-
You can't guarantee trades will be profitable, but I like the idea.
The committee is currently long 6910 USD, 7860 CNY, and .473BTC these positions are not guaranteed profitable positions to hold either.
We need to create bitassets and sell them into the market for liquidity not worry about the profits from it.
-
You can't guarantee trades will be profitable, but I like the idea.
The committee is currently long 6910 USD, 7860 CNY, and .473BTC these positions are not guaranteed profitable positions to hold either.
We need to create bitassets and sell them into the market for liquidity not worry about the profits from it.
If those 6k would be divided between 3-6 different members doing some market making on the DEX it could help get some traction.
I say not sell them but have that spread on people who can do market making and of course, we can trust. Multi sig account shared with committee members or other trustworthy people with more weight over the account.
-
You can't guarantee trades will be profitable, but I like the idea.
The committee is currently long 6910 USD, 7860 CNY, and .473BTC these positions are not guaranteed profitable positions to hold either.
We need to create bitassets and sell them into the market for liquidity not worry about the profits from it.
If those 6k would be divided between 3-6 different members doing some market making on the DEX it could help get some traction.
I say not sell them but have that spread on people who can do market making and of course, we can trust. Multi sig account shared with committee members or other trustworthy people with more weight over the account.
Thats too complex. Just put the lot up for sale at feed +7% and release them back in to market place.
This adds instant market depth on the sell side where it is most lacking.
Then return the bts from the sale back to the reserve pool.
-
You can't guarantee trades will be profitable, but I like the idea.
The committee is currently long 6910 USD, 7860 CNY, and .473BTC these positions are not guaranteed profitable positions to hold either.
We need to create bitassets and sell them into the market for liquidity not worry about the profits from it.
If those 6k would be divided between 3-6 different members doing some market making on the DEX it could help get some traction.
I say not sell them but have that spread on people who can do market making and of course, we can trust. Multi sig account shared with committee members or other trustworthy people with more weight over the account.
Thats too complex. Just put the lot up for sale at feed +7% and release them back in to market place.
This adds instant market depth on the sell side where it is most lacking.
Then return the bts from the sale back to the reserve pool.
That seems only a momentarily solution. 6k isn't that much. What happens once they're gone? Having market makers use that can keep liquidity for longer until people start slowly adhering to the peg. Just throwing those in the wild with no plan doesn't make sense.
It's nice if you want to pick up cheap assets and 7% above the feed and sell them again at 20 or 30% above and make some profit :) it's bad for BitShares not having a longer term plan
-
I'm a fan of providing an incentive to market makers. I would prefer that incentive cone from a worker proposal.
Selling these bitassets is really just getting back to par as par.
-
You can't guarantee trades will be profitable, but I like the idea.
The committee is currently long 6910 USD, 7860 CNY, and .473BTC these positions are not guaranteed profitable positions to hold either.
We need to create bitassets and sell them into the market for liquidity not worry about the profits from it.
If those 6k would be divided between 3-6 different members doing some market making on the DEX it could help get some traction.
I say not sell them but have that spread on people who can do market making and of course, we can trust. Multi sig account shared with committee members or other trustworthy people with more weight over the account.
Thats too complex. Just put the lot up for sale at feed +7% and release them back in to market place.
This adds instant market depth on the sell side where it is most lacking.
Then return the bts from the sale back to the reserve pool.
That seems only a momentarily solution. 6k isn't that much. What happens once they're gone? Having market makers use that can keep liquidity for longer until people start slowly adhering to the peg. Just throwing those in the wild with no plan doesn't make sense.
It's nice if you want to pick up cheap assets and 7% above the feed and sell them again at 20 or 30% above and make some profit :) it's bad for BitShares not having a longer term plan
Selling at feed +5% +7% +10% +20% or whatever is market making.
If you spread it across 6 trusted people with multi sig it will still get sold just as quick.
The trouble is there isn't enough bitassets sloshing around at the moment which is why i think maybe it makes sense to create more bit assets using reserve pool bts.
This would stop a manipulator from buying up all of the available bitasset and refusing to sell to those trying to cover unless they pay a 30% premium over feed.
-
I'm a fan of providing an incentive to market makers. I would prefer that incentive cone from a worker proposal.
Selling these bitassets is really just getting back to par as par.
I am too. I like some of the market maker ideas here. That could take a little more time, however it could be a more long term solution. I like the idea of a shared pool that was suggested that the committee funds could just participate in.
Sadly this is not an option in the poll that was started so I can't really cast my preference other than 'other'.
One thing though.. how would it be decided which markets get funded?
-
I'm a fan of providing an incentive to market makers. I would prefer that incentive cone from a worker proposal.
Selling these bitassets is really just getting back to par as par.
I am too. I like some of the market maker ideas here. That could take a little more time, however it could be a more long term solution. I like the idea of a shared pool that was suggested that the committee funds could just participate in.
Sadly this is not an option in the poll that was started so I can't really cast my preference other than 'other'.
One thing though.. how would it be decided which markets get funded?
My preference is that as a committee we would simply sell the assets back into the market and use those funds to fund the fee pool.
If we went further than that the smart thing to do would be to start with our largest bitasset that also tends towards being overpriced. Specifically bitusd. The fair thing to do, would be to spend the proceeds of each assets fee pool on extra liquidity for that asset.
-
I'm a fan of providing an incentive to market makers. I would prefer that incentive cone from a worker proposal.
Selling these bitassets is really just getting back to par as par.
I am too. I like some of the market maker ideas here. That could take a little more time, however it could be a more long term solution. I like the idea of a shared pool that was suggested that the committee funds could just participate in.
Sadly this is not an option in the poll that was started so I can't really cast my preference other than 'other'.
One thing though.. how would it be decided which markets get funded?
My preference is that as a committee we would simply sell the assets back into the market and use those funds to fund the fee pool.
If we went further than that the smart thing to do would be to start with our largest bitasset that also tends towards being overpriced. Specifically bitusd. The fair thing to do, would be to spend the proceeds of each assets fee pool on extra liquidity for that asset.
Option 1 was my preference next to some kind of MM pool that has been talked about.
I would hope by bringing some liquidity to the markets we do bring pricing into tighter margins but with what we have thus far and what we should keep in reserve for fees I don't imagine it would make much of a dent atm. That's why I think a longer term solution I think would be an MM pool with committee involvement.
-
My preference is that as a committee we would simply sell the assets back into the market and use those funds to fund the fee pool.
If we went further than that the smart thing to do would be to start with our largest bitasset that also tends towards being overpriced. Specifically bitusd. The fair thing to do, would be to spend the proceeds of each assets fee pool on extra liquidity for that asset.
I also think that this is very reasonable thing to do at this moment.
-
My preference is that as a committee we would simply sell the assets back into the market and use those funds to fund the fee pool.
If we went further than that the smart thing to do would be to start with our largest bitasset that also tends towards being overpriced. Specifically bitusd. The fair thing to do, would be to spend the proceeds of each assets fee pool on extra liquidity for that asset.
I also think that this is very reasonable thing to do at this moment.
I like this idea too
-
I'm a fan of providing an incentive to market makers. I would prefer that incentive cone from a worker proposal.
Selling these bitassets is really just getting back to par as par.
I am too. I like some of the market maker ideas here. That could take a little more time, however it could be a more long term solution. I like the idea of a shared pool that was suggested that the committee funds could just participate in.
Sadly this is not an option in the poll that was started so I can't really cast my preference other than 'other'.
One thing though.. how would it be decided which markets get funded?
My preference is that as a committee we would simply sell the assets back into the market and use those funds to fund the fee pool.
If we went further than that the smart thing to do would be to start with our largest bitasset that also tends towards being overpriced. Specifically bitusd. The fair thing to do, would be to spend the proceeds of each assets fee pool on extra liquidity for that asset.
Option 1 was my preference next to some kind of MM pool that has been talked about.
I would hope by bringing some liquidity to the markets we do bring pricing into tighter margins but with what we have thus far and what we should keep in reserve for fees I don't imagine it would make much of a dent atm. That's why I think a longer term solution I think would be an MM pool with committee involvement.
Have you discussed that with committee members? I would like to see that. I think it's better to take initiative on that and find our own solutions instead of waiting for CNX to develop MAKER as that might take a while, plus, by then, we might already have a little more volume
-
The bitassets created would get sold on the market at say feed price +7% and then the bts from that sale returned to the reserve pool or fee pool.
A committee run account would have create these new bitassets and once created and sold that account would have 300% collateral positions for the 100% bitassets it created.
On telegram with @mindplux @iHashFury we discussed the idea of a committee controlled account which could create $50,000 bitUSD and then destroying the private key for that committee controlled account.
This would create a good base supply of bitusd to jumpstart the dex and get it moving. If a worker proposal wasn't continuous and ended it would still be providing liquidty because there would be more bitassets sloshing around in the system in general.
However! those 300% ($150000) worth of BTS would be lost forever. so the equivalent of a burn really.
You could offset this loss/burn by adding a recurring payment from the committe controlled account that gets deleted so that any bts from forced settlements in the committee account would be returned to the reserve pool.
I think this idea could make sense as a one hit or injection of liquidity to the dex.
-
The bitassets created would get sold on the market at say feed price +7% and then the bts from that sale returned to the reserve pool or fee pool.
A committee run account would have create these new bitassets and once created and sold that account would have 300% collateral positions for the 100% bitassets it created.
On telegram with @mindplux @iHashFury we discussed the idea of a committee controlled account which could create $50,000 bitUSD and then destroying the private key for that committee controlled account.
This would create a good base supply of bitusd to jumpstart the dex and get it moving. If a worker proposal wasn't continuous and ended it would still be providing liquidty because there would be more bitassets sloshing around in the system in general.
However! those 300% ($150000) worth of BTS would be lost forever. so the equivalent of a burn really.
You could offset this loss/burn by adding a recurring payment from the committe controlled account that gets deleted so that any bts from forced settlements in the committee account would be returned to the reserve pool.
I think this idea could make sense as a one hit or injection of liquidity to the dex.
So the worker would dilute BTS, however the bts created from that dilution would be locked away forever, meaning there would be no true excess of BTS supply right?
But couldn't that restrict our future reserve pool, form which we can get funding for other features? Since our pool is limited and we would permanently remove 150k from our future budget to fund other features?
-
The bitassets created would get sold on the market at say feed price +7% and then the bts from that sale returned to the reserve pool or fee pool.
A committee run account would have create these new bitassets and once created and sold that account would have 300% collateral positions for the 100% bitassets it created.
On telegram with @mindplux @iHashFury we discussed the idea of a committee controlled account which could create $50,000 bitUSD and then destroying the private key for that committee controlled account.
This would create a good base supply of bitusd to jumpstart the dex and get it moving. If a worker proposal wasn't continuous and ended it would still be providing liquidty because there would be more bitassets sloshing around in the system in general.
However! those 300% ($150000) worth of BTS would be lost forever. so the equivalent of a burn really.
You could offset this loss/burn by adding a recurring payment from the committe controlled account that gets deleted so that any bts from forced settlements in the committee account would be returned to the reserve pool.
I think this idea could make sense as a one hit or injection of liquidity to the dex.
So the worker would dilute BTS, however the bts created from that dilution would be locked away forever, meaning there would be no true excess of BTS supply right?
But couldn't that restrict our future reserve pool, form which we can get funding for other features? Since our pool is limited and we would permanently remove 150k from our future budget to fund other features?
Yes it would be locked away forever. so not a real dilution.
yes it would be gone unless a recurring payment was set up to return any(settled by others) bts back to the reserve pool.
-
So I guess it's up to the community to decide if it's worth to lock 150k for ever and get a good amount of liquidity vs loosing 150k for future development. It's like short term vs long term. Or what could the community spend those 150k on that could be better than 50k bitUSD and a tighter peg. Would like to see a thread for a proposal like that to know people's opinions.
-
So I guess it's up to the community to decide if it's worth to lock 150k for ever and get a good amount of liquidity vs loosing 150k for future development. It's like short term vs long term. Or what could the community spend those 150k on that could be better than 50k bitUSD and a tighter peg. Would like to see a thread for a proposal like that to know people's opinions.
$150,000 locked up will not put any sell pressure on the bts price unlike if we paid it to a developer for salary.
With recurring bts payments setup back to the reserve pool set up these bts will be returned back over time.
-
So I guess it's up to the community to decide if it's worth to lock 150k for ever and get a good amount of liquidity vs loosing 150k for future development. It's like short term vs long term. Or what could the community spend those 150k on that could be better than 50k bitUSD and a tighter peg. Would like to see a thread for a proposal like that to know people's opinions.
$150,000 locked up will not put any sell pressure on the bts price unlike if we paid it to a developer for salary.
With recurring bts payments setup back to the reserve pool set up these bts will be returned back over time.
So that way we could "boost" liquidity and as it gains traction over time, we could get those 150k back over time and the markets (theoretically) would continue to stay liquid? Or even move on to other market pairs? Sounds good.
Would like to hear more people's opinion on this in case there are some drawbacks I'm not seeing here.
-
I see two drawbacks to this proposal (basically option 3 with greater detail)
First of all is economics. We are not completely sure what the effect on the peg will be of adding all of these assets. Adding so much sell pressure could push the price below the peg. I think this could largely be alleviated by adding the liquidity slowly in say chunks of 1-5k uUSD watching the results, and keeping enough bts in the committee account to purchase back USD and close the short if needed. To help prevent manipulation, or accusations of manipulation it would be best if our targets, and decision points were spelled out ahead of time.
Second is politics. Adding this kind of funding to the committee account makes it a much greater target for coercion or collusion.
I'm not saying we shouldn't do it, these are just a couple of things we need to be careful about. I am sure there are other risks as well.
-
First of all is economics. We are not completely sure what the effect on the peg will be of adding all of these assets.
None? You cannot change the external price of a bitAsset by buying or selling it - you have to buy/sell an IOU of the real thing to do that.
-
The bitassets created would get sold on the market at say feed price +7% and then the bts from that sale returned to the reserve pool or fee pool.
A committee run account would have create these new bitassets and once created and sold that account would have 300% collateral positions for the 100% bitassets it created.
On telegram with @mindplux @iHashFury we discussed the idea of a committee controlled account which could create $50,000 bitUSD and then destroying the private key for that committee controlled account.
This would create a good base supply of bitusd to jumpstart the dex and get it moving. If a worker proposal wasn't continuous and ended it would still be providing liquidty because there would be more bitassets sloshing around in the system in general.
However! those 300% ($150000) worth of BTS would be lost forever. so the equivalent of a burn really.
You could offset this loss/burn by adding a recurring payment from the committe controlled account that gets deleted so that any bts from forced settlements in the committee account would be returned to the reserve pool.
I think this idea could make sense as a one hit or injection of liquidity to the dex.
I'm not very enthusiastic about burn workers in general, but if we are going to have one, this is the best option presented so far. Of course it's best to first create some MPA's, sold them on the exchange and then burn the BTS, rather than burn the BTS immediately without any additional benefits.
-
First of all is economics. We are not completely sure what the effect on the peg will be of adding all of these assets.
None? You cannot change the external price of a bitAsset by buying or selling it - you have to buy/sell an IOU of the real thing to do that.
I'm not talking about changing the feed price of USD vs bts. I'm talking about how close the actual price measured by transactions on the dex, and external exchanges is to that feed price.
-
I see two drawbacks to this proposal (basically option 3 with greater detail)
First of all is economics. We are not completely sure what the effect on the peg will be of adding all of these assets. Adding so much sell pressure could push the price below the peg. I think this could largely be alleviated by adding the liquidity slowly in say chunks of 1-5k uUSD watching the results, and keeping enough bts in the committee account to purchase back USD and close the short if needed. To help prevent manipulation, or accusations of manipulation it would be best if our targets, and decision points were spelled out ahead of time.
Second is politics. Adding this kind of funding to the committee account makes it a much greater target for coercion or collusion.
I'm not saying we shouldn't do it, these are just a couple of things we need to be careful about. I am sure there are other risks as well.
Can't we just settle if the price is below feed? That's instant profit and a good enough incentive not to get it below feed.
-
You are bunch of *explicit* lead by *explicit* *explicit*.
And yes I am talking about the vocal majority on this forum (not the stakeholder majority). Just think twice when you post next time - "I am here for the long run, I do not care about the price." Cause when you say I do not care about the price, all you are actually saying is " I do not give a damn about liquidity"... and if so you wish, you will have a long road ahead of you... a long road of lack of liquidity...
I know your leader taught you that but it is a statement as wrong as it can get. The price matters A LOT... actually the price is one of the very few things that do matter!
And on a side note - the price... and the wrong take on It is why you are now considered the "group trappers of BM"... well that and his believe that spending and losing millions of dollars and not delivering a finished product is somehow something to be held against the funds providers... and completely 'failing' to see his part in the 'money being gone and no product to show for them'...
-
You are bunch of *explicit* lead by *explicit* *explicit*.
And yes I am talking about the vocal majority on this forum (not the stakeholder majority). Just think twice when you post next time - "I am here for the long run, I do not care about the price." Cause when you say I do not care about the price, all you are actually saying is " I do not give a damn about liquidity"... and if so you wish, you will have a long road ahead of you... a long road of lack of liquidity...
I know your leader taught you that but it is a statement as wrong as it can get. The price matters A LOT... actually the price is one of the very few things that do matter!
And on a side note - the price... and the wrong take on It is why you are now considered the "group trappers of BM"... well that and his believe that spending and losing millions of dollars and not delivering a finished product is somehow something to be held against the funds providers... and completely 'failing' to see his part in the 'money being gone and no product to show for them'...
Could you share why the proposed seems like a bad/good idea to you? Why you agree/don't agree?
-
You are bunch of *explicit* lead by *explicit* *explicit*.
And yes I am talking about the vocal majority on this forum (not the stakeholder majority). Just think twice when you post next time - "I am here for the long run, I do not care about the price." Cause when you say I do not care about the price, all you are actually saying is " I do not give a damn about liquidity"... and if so you wish, you will have a long road ahead of you... a long road of lack of liquidity...
I know your leader taught you that but it is a statement as wrong as it can get. The price matters A LOT... actually the price is one of the very few things that do matter!
And on a side note - the price... and the wrong take on It is why you are now considered the "group trappers of BM"... well that and his believe that spending and losing millions of dollars and not delivering a finished product is somehow something to be held against the funds providers... and completely 'failing' to see his part in the 'money being gone and no product to show for them'...
Could you share why the proposed seems like a bad/good idea to you? Why you agree/don't agree?
What will non-market measures do against the force of the market? Very little to nothing... fix the fundamental flow, the market desiring to short bitasset and sell them for profit is what is needed, not half-ass non market measures -> your leader should start caring about the price ...and not think "well the price does not matter I just price my worker-fees in USD convert them in BTS per day by multiplying by the whatever current price of BTS is...viola the price is just an insignificant variable for my purposes."
Start requiring market sensitive actions from your leader...hell start with not gladly accepting his arrogance in claiming you trapped him in non profitable position, when clearly his actions [failing to sell at high price the AGS BTC, yet paying taxes on that high price bases] and non delivery of finished product lead to millions of dollars down the drain in 2014, and the need for new money (bigger trap as he would say) and smaller stake for him due to the need to sell [apparently] the AGS BTS to cover costs.... start rejecting his brownie crumbles for being obedient to him, but rather demand he to finish what he has started (and I mean not finish it to the 75% done mark).... maker, percent fees, bond market/lending, prediction market....
Stop voting for proposals that will make the price go down... what is the F**ing stealth gonna do for your exchange and bitassets? Nothing other than delaying other feature. Are gonna be able to stealthly trade? NO! just the existing big group trappers will be able to claim their balances 'secretly'... the market does not care about your stash secret or otherwise. Nor do the new coming customers.
-
You are bunch of *explicit* lead by *explicit* *explicit*.
And yes I am talking about the vocal majority on this forum (not the stakeholder majority). Just think twice when you post next time - "I am here for the long run, I do not care about the price." Cause when you say I do not care about the price, all you are actually saying is " I do not give a damn about liquidity"... and if so you wish, you will have a long road ahead of you... a long road of lack of liquidity...
I know your leader taught you that but it is a statement as wrong as it can get. The price matters A LOT... actually the price is one of the very few things that do matter!
And on a side note - the price... and the wrong take on It is why you are now considered the "group trappers of BM"... well that and his believe that spending and losing millions of dollars and not delivering a finished product is somehow something to be held against the funds providers... and completely 'failing' to see his part in the 'money being gone and no product to show for them'...
Could you share why the proposed seems like a bad/good idea to you? Why you agree/don't agree?
What will non-market measures do against the force of the market? Very little to nothing... fix the fundamental flow, the market desiring to short bitasset and sell them for profit is what is needed, not half-ass non market measures -> your leader should start caring about the price ...and not think "well the price does not matter I just price my worker-fees in USD convert them in BTS per day by multiplying by the whatever current price of BTS is...viola the price is just an insignificant variable for my purposes."
Start requiring market sensitive actions from your leader...hell start with not gladly accepting his arrogance in claiming you trapped him in non profitable position, when clearly his actions [failing to sell at high price the AGS BTC, yet paying taxes on that high price bases] and non delivery of finished product lead to millions of dollars down the drain in 2014, and the need for new money (bigger trap as he would say) and smaller stake for him due to the need to sell [apparently] the AGS BTS to cover costs.... start rejecting his brownie crumbles for being obedient to him, but rather demand he to finish what he has started (and I mean not finish it to the 75% done mark).... maker, percent fees, bond market/lending, prediction market....
Stop voting for proposals that will make the price go down... what is the F**ing stealth gonna do for your exchange and bitassets? Nothing other than delaying other feature. Are gonna be able to stealthly trade? NO! just the existing big group trappers will be able to claim their balances 'secretly'... the market does not care about your stash secret or otherwise. Nor do the new coming customers.
So basically what you're saying is we should benefit shorts right? Well, I agree that the collateral to short bitAssets into existence is too high and that puts people off...
Are there any reasons why decreasing collateral to 150% is a problem? It might be more risky, but still.. we need to find a balance.
-
You are bunch of *explicit* lead by *explicit* *explicit*.
And yes I am talking about the vocal majority on this forum (not the stakeholder majority). Just think twice when you post next time - "I am here for the long run, I do not care about the price." Cause when you say I do not care about the price, all you are actually saying is " I do not give a damn about liquidity"... and if so you wish, you will have a long road ahead of you... a long road of lack of liquidity...
I know your leader taught you that but it is a statement as wrong as it can get. The price matters A LOT... actually the price is one of the very few things that do matter!
And on a side note - the price... and the wrong take on It is why you are now considered the "group trappers of BM"... well that and his believe that spending and losing millions of dollars and not delivering a finished product is somehow something to be held against the funds providers... and completely 'failing' to see his part in the 'money being gone and no product to show for them'...
Could you share why the proposed seems like a bad/good idea to you? Why you agree/don't agree?
What will non-market measures do against the force of the market? Very little to nothing... fix the fundamental flow, the market desiring to short bitasset and sell them for profit is what is needed, not half-ass non market measures -> your leader should start caring about the price ...and not think "well the price does not matter I just price my worker-fees in USD convert them in BTS per day by multiplying by the whatever current price of BTS is...viola the price is just an insignificant variable for my purposes."
Start requiring market sensitive actions from your leader...hell start with not gladly accepting his arrogance in claiming you trapped him in non profitable position, when clearly his actions [failing to sell at high price the AGS BTC, yet paying taxes on that high price bases] and non delivery of finished product lead to millions of dollars down the drain in 2014, and the need for new money (bigger trap as he would say) and smaller stake for him due to the need to sell [apparently] the AGS BTS to cover costs.... start rejecting his brownie crumbles for being obedient to him, but rather demand he to finish what he has started (and I mean not finish it to the 75% done mark).... maker, percent fees, bond market/lending, prediction market....
Stop voting for proposals that will make the price go down... what is the F**ing stealth gonna do for your exchange and bitassets? Nothing other than delaying other feature. Are gonna be able to stealthly trade? NO! just the existing big group trappers will be able to claim their balances 'secretly'... the market does not care about your stash secret or otherwise. Nor do the new coming customers.
So basically what you're saying is we should benefit shorts right? Well, I agree that the collateral to short bitAssets into existence is too high and that puts people off...
Are there any reasons why decreasing collateral to 150% is a problem? It might be more risky, but still.. we need to find a balance.
No, the collateral is fine now.... at least this was fixed...miraculously as this might sound.
Just no one believes this train, called BTS, is headed in the right direction... Well, except the big mouths on the forum...but I am talking about people putting their money where their mouth is.... not 'the future is great... obedience and following directionless leadership is even greater ' plus fivers.
-
Then what other methods would you suggest to benefit shorts?
-
and of course you should sell/settle the bitAssets accumulated in the fee pool. What else should you do with them? Give them to BM to develop some mutually market unrelated pipe dream or to offset by a tiny fraction the group trap he had put himself into?
-
If we can increase liquidity. Even artificially. And that leads to a better peg. And people actually use our bit assets. That would be a great boon to the price. Lots of ifs in there I know.
Improving the peg is improving the product. Improving the product should help adoption and price.
I'm trying to find ways that we can improve things now. Without waiting for the devs to fix things, or complaining when they don't do what we want or think is best.
I'm doing this because I care about the price. In fact, I'm pissed about the price. The price is a direct reflection of how the market views the value of our product.
-
If we can increase liquidity. Even artificially. And that leads to a better peg. And people actually use our bit assets. That would be a great boon to the price. Lots of ifs in there I know.
Improving the peg is improving the product. Improving the product should help adoption and price.
I'm trying to find ways that we can improve things now. Without waiting for the devs to fix things, or complaining when they don't do what we want or think is best.
I'm doing this because I care about the price. In fact, I'm pissed about the price. The price is a direct reflection of how the market views the value of our product.
Good!
1.Think what is most important about the price - fundamentals, direction, leadership vision... Think about the CEO of a stock exchange flat out declaring "Exchanges are no good for me... I need want something more profitable"
2.Start selling the collected fees in bitAssets tomorrow...start at 12-15% above feed and lower the price 0.5% every other day...
3. DO not be tempted to go after non-market solutions... DO not let Nubit 'success' tempt you for even a single second!
-
If we can increase liquidity. Even artificially. And that leads to a better peg. And people actually use our bit assets. That would be a great boon to the price. Lots of ifs in there I know.
Improving the peg is improving the product. Improving the product should help adoption and price.
I'm trying to find ways that we can improve things now. Without waiting for the devs to fix things, or complaining when they don't do what we want or think is best.
I'm doing this because I care about the price. In fact, I'm pissed about the price. The price is a direct reflection of how the market views the value of our product.
yes I also am pissed about the price to thanks for doing this @puppies
Nubits uses nushares holders funds to add liquidity and they have a successful usuable pegged coin
liquidity = better peg = more adoption = higher market cap
-
2.Start selling the collected fees in bitAssets tomorrow...start at 12-15% above feed and lower the price 0.5% every other day...
Yes this makes sense, put all the fee pool bit assets up for sale now at feedprice +15% and drop it each day until it's all sold.
This can be done now, and is nice and simple.
more complex ideas will take time and are less likely to get shareholder support.
-
2.Start selling the collected fees in bitAssets tomorrow...start at 12-15% above feed and lower the price 0.5% every other day...
Yes this makes sense, put all the fee pool bit assets up for sale now at feedprice +15% and drop it each day until it's all sold.
This can be done now, and is nice and simple.
more complex ideas will take time and are less likely to get shareholder support.
Agree.
Tony is a genius.
-
@puppies
ohh yes, and ask our leading exchange [i.e. storefront]- OpenLedger, why do they insist of behaving like obit-uary writers rather than a serious exchange?
ask them what is the f***en logic for offering to buy their own BTC IOU at 7% discount below market... at most?
-
2.Start selling the collected fees in bitAssets tomorrow...start at 12-15% above feed and lower the price 0.5% every other day...
Yes this makes sense, put all the fee pool bit assets up for sale now at feedprice +15% and drop it each day until it's all sold.
This can be done now, and is nice and simple.
more complex ideas will take time and are less likely to get shareholder support.
Agree.
Tony is a genius.
Yes, he is a lovable and helpful person when one sees beyond his spicy surface. I like that bright idea.
ohh yes, and ask our leading exchange [i.e. storefront]- OpenLedger, why do they insist of behaving like obit-uary writers rather than a serious exchange?
Perhaps their main business is obits (and not exchange)?
-
2.Start selling the collected fees in bitAssets tomorrow...start at 12-15% above feed and lower the price 0.5% every other day...
Yes this makes sense, put all the fee pool bit assets up for sale now at feedprice +15% and drop it each day until it's all sold.
This can be done now, and is nice and simple.
more complex ideas will take time and are less likely to get shareholder support.
Agree.
Tony is a genius.
Yes, he is a lovable and helpful person when one sees beyond his spicy surface. I like that bright idea.
I do wish though, you all have paid more attention to the serious (as spicy as they might be) other posts of mine in this thread, instead of this trivial and of little practical or long term benefits suggestion.[which in all likelihood is probably not even do-able as of yet, cause "this finished BTS 2.0, probably not quite support proposed transaction because of 'hard to catch if too lazy to test' bug, requiring a hard fork to fix"
ohh yes, and ask our leading exchange [i.e. storefront]- OpenLedger, why do they insist of behaving like obit-uary writers rather than a serious exchange?
Perhaps their main business is obits (and not exchange)?
As you might know, there is little doubt in my mind that this is exactly the case.
-
so, committee members, do you have something here with proposal potential?
@mindphlux @BunkerChain Labs @baozi @bitcrab
-
What should the committee do to support liquidity?
They can't do nothing to support liquidity. To support liquidity, you need capital. Your committee are beggars with naked ass.
-
so, committee members, do you have something here with proposal potential?
@mindphlux @BunkerChain Labs @baozi @bitcrab
I agree we should use the fund to support liquility.
and I agree tony's advice
-
so, committee members, do you have something here with proposal potential?
@mindphlux @BunkerChain Labs @baozi @bitcrab
I agree we should use the fund to support liquility.
and I agree tony's advice
Make a proposal please?
-
so, committee members, do you have something here with proposal potential?
@mindphlux @BunkerChain Labs @baozi @bitcrab
I agree we should use the fund to support liquility.
and I agree tony's advice
Make a proposal please?
Can you discuss that here/telegram and see if you can come up with a proposal?
-
I decided that I would indeed put my other project aside and work on a MM/Arbitrage bot that anyone can download and run on their computer alongside a CLI wallet. I am trying to make it stupidly easy to use so that my grandma could run it... I will be open sourcing it after I am happy that it is safe to for someone to run (won't lose a ton of money haha.)
Done:
- I got the wireframe just about done today: http://imgur.com/a/FelFn
- The settings are saved in a Mongo database (in case you need to reboot your computer, close the bot, etc..)
- You can access the bot from any computer with an internet connection if you forward the web server port
To-Do:
- I will add the ability to create a username and password for added security since you can access the bot from other computers if the port is forwarded.
- Write the Bitshares CLI wallet library
- Write the first exchange (Poloniex) library
- Write a MM/Arbitrage Logic library
I am going to firstly make sure it has the ability to perform arbitrage trades across all BTS/bitAsset markets (centralized exchanges and Bitshare's DEX.) I think that is much easier than making a MM bot. If I can finish that I may move onto some MM-like functions. In other words.. all of the hard stuff left to do. :-X :'(
-
This thread was @puppies getting community feedback on this prospect.
With all that has been suggested the committee can take it all into consideration and consult on the matter and come to a decision.
Everyones input was helpful.
-
so, committee members, do you have something here with proposal potential?
@mindphlux @BunkerChain Labs @baozi @bitcrab
I agree we should use the fund to support liquility.
and I agree tony's advice
Make a proposal please?
Can you discuss that here/telegram and see if you can come up with a proposal?
In order to actually perform tony's idea, I see two options
- stick with multisig and have all committee members agree on
* withdraw accumulated fees
* place order
* cancel order
which is IMHO quite an overhead
instead I would propose to either pick a trusted committee/non-committee member that knows about
trading (read: not me) that can perform the trades on a new/empty account. Pay him a flat .5-1% or so
for his efforts
Just my thoughts
-
so, committee members, do you have something here with proposal potential?
@mindphlux @BunkerChain Labs @baozi @bitcrab
I agree we should use the fund to support liquility.
and I agree tony's advice
Make a proposal please?
Can you discuss that here/telegram and see if you can come up with a proposal?
In order to actually perform tony's idea, I see two options
- stick with multisig and have all committee members agree on
* withdraw accumulated fees
* place order
* cancel order
which is IMHO quite an overhead
instead I would propose to either pick a trusted committee/non-committee member that knows about
trading (read: not me) that can perform the trades on a new/empty account. Pay him a flat .5-1% or so
for his efforts
Just my thoughts
Yeah this makes sense, I know trading and would do it but I don't think I'm trusted yet.
-
Funds can of course also be split up :)
-
Funds can of course also be split up :)
A short 15 min script can also be written.
I wonder who could possibly have the skills to do it???? ;)
-
Funds can of course also be split up :)
A short 15 min script can also be written.
I wonder who could possibly have the skills to do it???? ;)
Do it tony! do it!
-
Funds can of course also be split up :)
A short 15 min script can also be written.
I wonder who could possibly have the skills to do it???? ;)
Sure .. But for whom? The committe members? or a single trusted entity?
-
Funds can of course also be split up :)
A short 15 min script can also be written.
I wonder who could possibly have the skills to do it???? ;)
Sure .. But for whom? The committe members? or a single trusted entity?
I think the core (proposed transactions functionality) can used and reused in a lot of cases.
So something for anyone. The user inputs her credentials/keys for her multi-sig account(s) and each day when running the script all existing proposals pop up for approval/rejection. and there is one more option - add new proposed tx.
PS
And for this particular case I do not know... let the committee decide. If it is too much work to do it themselves each day... they can send the funds to trusted party(s) even mid process...using the same tool even.
-
Funds can of course also be split up :)
A short 15 min script can also be written.
I wonder who could possibly have the skills to do it???? ;)
Sure .. But for whom? The committe members? or a single trusted entity?
I think the core (proposed transactions functionality) can used and reused in a lot of cases.
So something for anyone. The user inputs her credentials/keys for her multi-sig account(s) and each day when running the script all existing proposals pop up for approval/rejection. and there is one more option - add new proposed tx.
PS
And for this particular case I do not know... let the committee decide. If it is too much work to do it themselves each day... they can send the funds to trusted party(s) even mid process...using the same tool even.
A to-do list pops up every time when open the GUI? News, announcements & notices and some user-defined subscriptions? Sounds interesting.
//Edit: what if one never open the GUI?
-
So. the consensus seems to be option 1. Starting at 15% over feed and reducing daily until all funds are gone. I would also suggest a hard lower limit of 105%
As Xeroc mentioned the difficulty with that is that the committee account cannot place orders in real time. We need to submit a proposal, and have it approved by the majority of the committee. We are a very diverse set of people from around the globe, and coordinating that could be difficult.
I still think leaving these funds in the hands of the committee is the best option if we can pull it off. If we set the proposal for somewhere between a 2 and 4 hour window everyday, we should be able to find a time where all committee members can log in and approve.
Does anyone else think I should reset the results of the poll? Enough people in this thread have stated that they voted for the wrong thing in the poll.
-
Wanted to improve my library for market actions anyway :)
Extending it for proposed transaction should be doable as well ..
-
Wanted to improve my library for market actions anyway :)
Extending it for proposed transaction should be doable as well ..
Worst case scenario I could probably construct it manually. Thanks to your docs.
Should just be create a builder, add a market order, add fees, publish. Right?
What I am unsure of is the operation to withdraw the collected funds from the fee pool.
-
Wanted to improve my library for market actions anyway :)
Extending it for proposed transaction should be doable as well ..
Worst case scenario I could probably construct it manually. Thanks to your docs.
Should just be create a builder, add a market order, add fees, publish. Right?
Right
What I am unsure of is the operation to withdraw the collected funds from the fee pool.
It took me a while .. but the operation is called
asset_claim_fees_operation
and looks like this
get_prototype_operation asset_claim_fees_operation
[
43,{
"fee": {
"amount": 0,
"asset_id": "1.3.0"
},
"issuer": "1.2.0",
"amount_to_claim": {
"amount": 0,
"asset_id": "1.3.0"
},
"extensions": []
}
]
I will write a script that proposes to claim all available accumulated funds into the committee account and publish it later
-
Here we go. Now you need to convince the committee to approve
https://bitsharestalk.org/index.php/topic,20880.new.html#new
-
Here we go. Now you need to convince the committee to approve
https://bitsharestalk.org/index.php/topic,20880.new.html#new
Thanks for the efforts.
"Review begins in 14 days" Can it be earlier?
-
Thanks for the efforts.
"Review begins in 14 days" Can it be earlier?
Sure .. but only with a new proposal. I think we should take the 2 weeks and figure out what to do with the funds and not rush into something .. This would also allow me to properly code a script and test it until the funds are release (or not)
Maybe you can enlighten me about a detail: Is the review period right before the expiration of a proposal or is the review period first and no one can vote within that period?
-
Thanks for the efforts.
"Review begins in 14 days" Can it be earlier?
Sure .. but only with a new proposal. I think we should take the 2 weeks and figure out what to do with the funds and not rush into something .. This would also allow me to properly code a script and test it until the funds are release (or not)
It makes sense to me.
Maybe you can enlighten me about a detail: Is the review period right before the expiration of a proposal or is the review period first and no one can vote within that period?
I think it's more likely to be the former.
-
Thanks for the efforts.
"Review begins in 14 days" Can it be earlier?
Sure .. but only with a new proposal. I think we should take the 2 weeks and figure out what to do with the funds and not rush into something .. This would also allow me to properly code a script and test it until the funds are release (or not)
Maybe you can enlighten me about a detail: Is the review period right before the expiration of a proposal or is the review period first and no one can vote within that period?
Thanks for putting up the work and giving the committee members some time to discuss the matter and come up with an action plan.
I think the review period is before the proposal expiration and no one can vote during the review period.
-
I think the review period is before the proposal expiration and no one can vote during the review period.
I don't think so. If no one can vote, how to "review"?
//Edit:
According to the comments in the code, the review period is a configurable parameter, and it should be able to voting during the period:
FC_ASSERT( !o.review_period_seconds || fc::seconds(*o.review_period_seconds) < (o.expiration_time - d.head_block_time()),
"Proposal review period must be less than its overall lifetime." );
{
// If we're dealing with the committee authority, make sure this transaction has a sufficient review period.
https://github.com/bitshares/bitshares-2/blob/bitshares/libraries/chain/proposal_evaluator.cpp#L39-L43
//Edit2:
I may be wrong here. Will check. If it's the case I'll update the post later.
//Edit3:
According to the code, it's unable to approve the proposal during the review period (don't know if it's possible to decline an earlier approval though). And sure it's possible to vote in/out who approved the proposal from committee -- this action is called "review".
if( _proposal->review_period_time && d.head_block_time() >= *_proposal->review_period_time )
FC_ASSERT( o.active_approvals_to_add.empty() && o.owner_approvals_to_add.empty(),
"This proposal is in its review period. No new approvals may be added." );
https://github.com/bitshares/bitshares-2/blob/bitshares/libraries/chain/proposal_evaluator.cpp#L113-L115
-
I think the review period is before the proposal expiration and no one can vote during the review period.
I don't think so. If no one can vote, how to "review"?
The review period is for shareholders to review their vote for their committee members and they can vote out the active members and vote in other non-active members.
-
I think the review period is before the proposal expiration and no one can vote during the review period.
I don't think so. If no one can vote, how to "review"?
The review period is for shareholders to review their vote for their committee members and they can vote out the active members and vote in other non-active members.
You are correct. I've updated my post.
-
The revie period for committee desicions is a blockchain parameter (currently 1h only) .. i put a 2 weeks expiration for the proposal itself .. that leads us a 2 weeks of time to come up with a reasonable idea hoe to proceed ..
Thanks for the clarification!
-
The poll at the top of this thread shows people are broadly in favour of selling the bitasset trade fees that have been accumulated.
yet only @mindphlux @dele-puppy and @BunkerChain Labs have approved it: http://cryptofresh.com/p/1.10.48
Could @baozi @bitcrab @bitcube also approve this action please.
-
If I'm not mistaken, baozi/ @alt has agreed to it too in some reply either to this thread or the one I made on the trading discussion section
-
The poll at the top of this thread shows people are broadly in favour of selling the bitasset trade fees that have been accumulated.
yet only @mindphlux @dele-puppy and @BunkerChain Labs have approved it: http://cryptofresh.com/p/1.10.48
Could @baozi @bitcrab @bitcube also approve this action please.
Please see https://bitsharestalk.org/index.php/topic,19542.msg270157.html#msg270157
We are in the middle of a discussion.
-
The poll at the top of this thread shows people are broadly in favour of selling the bitasset trade fees that have been accumulated.
yet only @mindphlux @dele-puppy and @BunkerChain Labs have approved it: http://cryptofresh.com/p/1.10.48
Could @baozi @bitcrab @bitcube also approve this action please.
how many people found the amount in this proposol is not correct?
-
The poll at the top of this thread shows people are broadly in favour of selling the bitasset trade fees that have been accumulated.
yet only @mindphlux @dele-puppy and @BunkerChain Labs have approved it: http://cryptofresh.com/p/1.10.48
Could @baozi @bitcrab @bitcube also approve this action please.
how many people found the amount in this proposol is not correct?
where can we see the collected trade fees on the gui or cryptofresh.com ?
-
The poll at the top of this thread shows people are broadly in favour of selling the bitasset trade fees that have been accumulated.
yet only @mindphlux @dele-puppy and @BunkerChain Labs have approved it: http://cryptofresh.com/p/1.10.48
Could @baozi @bitcrab @bitcube also approve this action please.
how many people found the amount in this proposol is not correct?
where can we see the collected trade fees on the gui or cryptofresh.com ?
you even don't know abou this, so how dare you encourage people to support this proposol?
I want ask you all again, is BTS just a play game or a serious business?
-
The poll at the top of this thread shows people are broadly in favour of selling the bitasset trade fees that have been accumulated.
yet only @mindphlux @dele-puppy and @BunkerChain Labs have approved it: http://cryptofresh.com/p/1.10.48
Could @baozi @bitcrab @bitcube also approve this action please.
how many people found the amount in this proposol is not correct?
where can we see the collected trade fees on the gui or cryptofresh.com ?
you even don't know abou this, so how dare you encourage people to support this proposol?
I want ask you all again, is BTS just a play game or a serious business?
I understand market mechanics well, I'm a trader. I can't code and I don't use the CLI client.
I understand what's being discussed and proposed.
I can see it now in both GUI and cryptofresh. its called "Unclaimed issuer income" on the gui and just "unclaimed" on cryptofresh sorry I didn't see it before.
I still don't understand fully understand the procedure to access these funds. Is it in a normal bts account controlled by the committee through multisig or what? please explain where these funds are held and exactly how they could be accessed for sale.
-
The poll at the top of this thread shows people are broadly in favour of selling the bitasset trade fees that have been accumulated.
yet only @mindphlux @dele-puppy and @BunkerChain Labs have approved it: http://cryptofresh.com/p/1.10.48
Could @baozi @bitcrab @bitcube also approve this action please.
how many people found the amount in this proposol is not correct?
//Update
Confirmed.
I've submitted a pull request which contains a fix to the script.
We need to propose a new proposal.
//Original post
Thanks for mention this. I checked and found that at least "asset_id" of "fee"s are strange. @xeroc ?
"fee": {
"amount": 668,
"asset_id": "1.3.120"
},
Proposed operation for claiming EUR fees:
{
"fee": {
"amount": 668,
"asset_id": "1.3.120"
},
"issuer": "1.2.0",
"amount_to_claim": {
"amount": 8899500,
"asset_id": "1.3.120"
},
"extensions": []
}
Available EUR fees (less than the amount above):
[{
"id": "2.3.120",
"current_supply": 9223814,
"confidential_supply": 0,
"accumulated_fees": 102449,
"fee_pool": 3234216787
}
]
-
Thanks abit. Do you want to create the new proposal or would you prefer someone else do it?
-
Thanks abit. Do you want to create the new proposal or would you prefer someone else do it?
Yes, I can do it.
So you prefer "expiration_time": "2016-01-18T23:59:59" still?
//Update:
Done.
http://cryptofresh.com/p/1.10.49
//Update 2:
Source code for proposing above proposal:
https://github.com/abitmore/python-graphenelib/blob/cb3539a2e5f8913e7bdb9c7d8b02228feffbaf75/scripts/witness-claim-accumulated-fees/main.py
-
Thanks again abit.
So I was playing a little bit trying to use the proposal_delete_operation. I was doing this manually in the wallet. I can create the builder. add the operation. Pay the correct fees. When I sign with false flag I get
unlocked >>> sign_builder_transaction 2 false
sign_builder_transaction 2 false
{
"ref_block_num": 6918,
"ref_block_prefix": 722491212,
"expiration": "2016-01-09T01:58:39",
"operations": [[
24,{
"fee": {
"amount": 200000,
"asset_id": "1.3.0"
},
"fee_paying_account": "1.2.1191",
"using_owner_authority": true,
"proposal": "1.10.48",
"extensions": []
}
]
],
"extensions": [],
"signatures": [
"2011ec79668c490caf27a8ce307c23ebaa26fd8170a53a33c2414c16db02486b38770b5131d8771d8a8dc5ca6c8d0cdec4361ec72af293cd4ed254abd442a37174"
]
}
unlocked >>>
But when I sign with true flag I get
unlocked >>> sign_builder_transaction 2 true
sign_builder_transaction 2 true
3554900ms th_a wallet.cpp:1919 sign_transaction ] Caught exception while broadcasting tx 07670ef5b21243f272b7c9b7c256380fcafa8ea8: 0 exception: unspecified
10 assert_exception: Assert Exception
required_approvals->find(o.fee_paying_account) != required_approvals->end(): Provided authority is not authoritative for this proposal.
{"provided":"1.2.1191","required":[]}
th_a proposal_evaluator.cpp:196 do_evaluate
{"o":{"fee":{"amount":200000,"asset_id":"1.3.0"},"fee_paying_account":"1.2.1191","using_owner_authority":true,"proposal":"1.10.48","extensions":[]}}
th_a proposal_evaluator.cpp:199 do_evaluate
{}
th_a evaluator.cpp:46 start_evaluate
{}
th_a db_block.cpp:653 apply_operation
{"trx":{"ref_block_num":6939,"ref_block_prefix":4113412531,"expiration":"2016-01-09T01:59:42","operations":[[24,{"fee":{"amount":200000,"asset_id":"1.3.0"},"fee_paying_account":"1.2.1191","using_owner_authority":true,"proposal":"1.10.48","extensions":[]}]],"extensions":[],"signatures":["20092147f99b4596202d2cafa54aa81e7a5330fb6adc5c7f3484f4e4f4b75e32132cc4bad1637d7a71a476feef30ac320418e0ff7e98cbf6750770d38257d06741"]}}
th_a db_block.cpp:636 _apply_transaction
{"trx":{"ref_block_num":6939,"ref_block_prefix":4113412531,"expiration":"2016-01-09T01:59:42","operations":[[24,{"fee":{"amount":200000,"asset_id":"1.3.0"},"fee_paying_account":"1.2.1191","using_owner_authority":true,"proposal":"1.10.48","extensions":[]}]],"extensions":[],"signatures":["20092147f99b4596202d2cafa54aa81e7a5330fb6adc5c7f3484f4e4f4b75e32132cc4bad1637d7a71a476feef30ac320418e0ff7e98cbf6750770d38257d06741"]}}
th_a db_block.cpp:220 push_transaction
{"error":"10 assert_exception: Assert Exception\nrequired_approvals->find(o.fee_paying_account) != required_approvals->end(): Provided authority is not authoritative for this proposal.\n {\"provided\":\"1.2.1191\",\"required\":[]}\n th_a proposal_evaluator.cpp:196 do_evaluate\n\n {\"o\":{\"fee\":{\"amount\":200000,\"asset_id\":\"1.3.0\"},\"fee_paying_account\":\"1.2.1191\",\"using_owner_authority\":true,\"proposal\":\"1.10.48\",\"extensions\":[]}}\n th_a proposal_evaluator.cpp:199 do_evaluate\n\n {}\n th_a evaluator.cpp:46 start_evaluate\n\n {}\n th_a db_block.cpp:653 apply_operation\n\n {\"trx\":{\"ref_block_num\":6939,\"ref_block_prefix\":4113412531,\"expiration\":\"2016-01-09T01:59:42\",\"operations\":[[24,{\"fee\":{\"amount\":200000,\"asset_id\":\"1.3.0\"},\"fee_paying_account\":\"1.2.1191\",\"using_owner_authority\":true,\"proposal\":\"1.10.48\",\"extensions\":[]}]],\"extensions\":[],\"signatures\":[\"20092147f99b4596202d2cafa54aa81e7a5330fb6adc5c7f3484f4e4f4b75e32132cc4bad1637d7a71a476feef30ac320418e0ff7e98cbf6750770d38257d06741\"]}}\n th_a db_block.cpp:636 _apply_transaction\n\n {\"trx\":{\"ref_block_num\":6939,\"ref_block_prefix\":4113412531,\"expiration\":\"2016-01-09T01:59:42\",\"operations\":[[24,{\"fee\":{\"amount\":200000,\"asset_id\":\"1.3.0\"},\"fee_paying_account\":\"1.2.1191\",\"using_owner_authority\":true,\"proposal\":\"1.10.48\",\"extensions\":[]}]],\"extensions\":[],\"signatures\":[\"20092147f99b4596202d2cafa54aa81e7a5330fb6adc5c7f3484f4e4f4b75e32132cc4bad1637d7a71a476feef30ac320418e0ff7e98cbf6750770d38257d06741\"]}}\n th_a db_block.cpp:220 push_transaction","data":{"id":184,"error":{"code":1,"message":"10 assert_exception: Assert Exception\nrequired_approvals->find(o.fee_paying_account) != required_approvals->end(): Provided authority is not authoritative for this proposal.\n {\"provided\":\"1.2.1191\",\"required\":[]}\n th_a proposal_evaluator.cpp:196 do_evaluate\n\n {\"o\":{\"fee\":{\"amount\":200000,\"asset_id\":\"1.3.0\"},\"fee_paying_account\":\"1.2.1191\",\"using_owner_authority\":true,\"proposal\":\"1.10.48\",\"extensions\":[]}}\n th_a proposal_evaluator.cpp:199 do_evaluate\n\n {}\n th_a evaluator.cpp:46 start_evaluate\n\n {}\n th_a db_block.cpp:653 apply_operation\n\n {\"trx\":{\"ref_block_num\":6939,\"ref_block_prefix\":4113412531,\"expiration\":\"2016-01-09T01:59:42\",\"operations\":[[24,{\"fee\":{\"amount\":200000,\"asset_id\":\"1.3.0\"},\"fee_paying_account\":\"1.2.1191\",\"using_owner_authority\":true,\"proposal\":\"1.10.48\",\"extensions\":[]}]],\"extensions\":[],\"signatures\":[\"20092147f99b4596202d2cafa54aa81e7a5330fb6adc5c7f3484f4e4f4b75e32132cc4bad1637d7a71a476feef30ac320418e0ff7e98cbf6750770d38257d06741\"]}}\n th_a db_block.cpp:636 _apply_transaction\n\n {\"trx\":{\"ref_block_num\":6939,\"ref_block_prefix\":4113412531,\"expiration\":\"2016-01-09T01:59:42\",\"operations\":[[24,{\"fee\":{\"amount\":200000,\"asset_id\":\"1.3.0\"},\"fee_paying_account\":\"1.2.1191\",\"using_owner_authority\":true,\"proposal\":\"1.10.48\",\"extensions\":[]}]],\"extensions\":[],\"signatures\":[\"20092147f99b4596202d2cafa54aa81e7a5330fb6adc5c7f3484f4e4f4b75e32132cc4bad1637d7a71a476feef30ac320418e0ff7e98cbf6750770d38257d06741\"]}}\n th_a db_block.cpp:220 push_transaction","data":{"code":10,"name":"assert_exception","message":"Assert Exception","stack":[{"context":{"level":"error","file":"proposal_evaluator.cpp","line":196,"method":"do_evaluate","hostname":"","thread_name":"th_a","timestamp":"2016-01-09T01:59:14"},"format":"required_approvals->find(o.fee_paying_account) != required_approvals->end(): Provided authority is not authoritative for this proposal.","data":{"provided":"1.2.1191","required":[]}},{"context":{"level":"warn","file":"proposal_evaluator.cpp","line":199,"method":"do_evaluate","hostname":"","thread_name":"th_a","timestamp":"2016-01-09T01:59:14"},"format":"","data":{"o":{"fee":{"amount":200000,"asset_id":"1.3.0"},"fee_paying_account":"1.2.1191","using_owner_authority":true,"proposal":"1.10.48","extensions":[]}}},{"context":{"level":"warn","file":"evaluator.cpp","line":46,"method":"start_evaluate","hostname":"","thread_name":"th_a","timestamp":"2016-01-09T01:59:14"},"format":"","data":{}},{"context":{"level":"warn","file":"db_block.cpp","line":653,"method":"apply_operation","hostname":"","thread_name":"th_a","timestamp":"2016-01-09T01:59:14"},"format":"","data":{}},{"context":{"level":"warn","file":"db_block.cpp","line":636,"method":"_apply_transaction","hostname":"","thread_name":"th_a","timestamp":"2016-01-09T01:59:14"},"format":"","data":{"trx":{"ref_block_num":6939,"ref_block_prefix":4113412531,"expiration":"2016-01-09T01:59:42","operations":[[24,{"fee":{"amount":200000,"asset_id":"1.3.0"},"fee_paying_account":"1.2.1191","using_owner_authority":true,"proposal":"1.10.48","extensions":[]}]],"extensions":[],"signatures":["20092147f99b4596202d2cafa54aa81e7a5330fb6adc5c7f3484f4e4f4b75e32132cc4bad1637d7a71a476feef30ac320418e0ff7e98cbf6750770d38257d06741"]}}},{"context":{"level":"warn","file":"db_block.cpp","line":220,"method":"push_transaction","hostname":"","thread_name":"th_a","timestamp":"2016-01-09T01:59:14"},"format":"","data":{"trx":{"ref_block_num":6939,"ref_block_prefix":4113412531,"expiration":"2016-01-09T01:59:42","operations":[[24,{"fee":{"amount":200000,"asset_id":"1.3.0"},"fee_paying_account":"1.2.1191","using_owner_authority":true,"proposal":"1.10.48","extensions":[]}]],"extensions":[],"signatures":["20092147f99b4596202d2cafa54aa81e7a5330fb6adc5c7f3484f4e4f4b75e32132cc4bad1637d7a71a476feef30ac320418e0ff7e98cbf6750770d38257d06741"]}}}]}}}}
th_a state.cpp:38 handle_reply
0 exception: unspecified
10 assert_exception: Assert Exception
required_approvals->find(o.fee_paying_account) != required_approvals->end(): Provided authority is not authoritative for this proposal.
{"provided":"1.2.1191","required":[]}
th_a proposal_evaluator.cpp:196 do_evaluate
{"o":{"fee":{"amount":200000,"asset_id":"1.3.0"},"fee_paying_account":"1.2.1191","using_owner_authority":true,"proposal":"1.10.48","extensions":[]}}
th_a proposal_evaluator.cpp:199 do_evaluate
{}
th_a evaluator.cpp:46 start_evaluate
{}
th_a db_block.cpp:653 apply_operation
{"trx":{"ref_block_num":6939,"ref_block_prefix":4113412531,"expiration":"2016-01-09T01:59:42","operations":[[24,{"fee":{"amount":200000,"asset_id":"1.3.0"},"fee_paying_account":"1.2.1191","using_owner_authority":true,"proposal":"1.10.48","extensions":[]}]],"extensions":[],"signatures":["20092147f99b4596202d2cafa54aa81e7a5330fb6adc5c7f3484f4e4f4b75e32132cc4bad1637d7a71a476feef30ac320418e0ff7e98cbf6750770d38257d06741"]}}
th_a db_block.cpp:636 _apply_transaction
{"trx":{"ref_block_num":6939,"ref_block_prefix":4113412531,"expiration":"2016-01-09T01:59:42","operations":[[24,{"fee":{"amount":200000,"asset_id":"1.3.0"},"fee_paying_account":"1.2.1191","using_owner_authority":true,"proposal":"1.10.48","extensions":[]}]],"extensions":[],"signatures":["20092147f99b4596202d2cafa54aa81e7a5330fb6adc5c7f3484f4e4f4b75e32132cc4bad1637d7a71a476feef30ac320418e0ff7e98cbf6750770d38257d06741"]}}
th_a db_block.cpp:220 push_transaction
{"error":"10 assert_exception: Assert Exception\nrequired_approvals->find(o.fee_paying_account) != required_approvals->end(): Provided authority is not authoritative for this proposal.\n {\"provided\":\"1.2.1191\",\"required\":[]}\n th_a proposal_evaluator.cpp:196 do_evaluate\n\n {\"o\":{\"fee\":{\"amount\":200000,\"asset_id\":\"1.3.0\"},\"fee_paying_account\":\"1.2.1191\",\"using_owner_authority\":true,\"proposal\":\"1.10.48\",\"extensions\":[]}}\n th_a proposal_evaluator.cpp:199 do_evaluate\n\n {}\n th_a evaluator.cpp:46 start_evaluate\n\n {}\n th_a db_block.cpp:653 apply_operation\n\n {\"trx\":{\"ref_block_num\":6939,\"ref_block_prefix\":4113412531,\"expiration\":\"2016-01-09T01:59:42\",\"operations\":[[24,{\"fee\":{\"amount\":200000,\"asset_id\":\"1.3.0\"},\"fee_paying_account\":\"1.2.1191\",\"using_owner_authority\":true,\"proposal\":\"1.10.48\",\"extensions\":[]}]],\"extensions\":[],\"signatures\":[\"20092147f99b4596202d2cafa54aa81e7a5330fb6adc5c7f3484f4e4f4b75e32132cc4bad1637d7a71a476feef30ac320418e0ff7e98cbf6750770d38257d06741\"]}}\n th_a db_block.cpp:636 _apply_transaction\n\n {\"trx\":{\"ref_block_num\":6939,\"ref_block_prefix\":4113412531,\"expiration\":\"2016-01-09T01:59:42\",\"operations\":[[24,{\"fee\":{\"amount\":200000,\"asset_id\":\"1.3.0\"},\"fee_paying_account\":\"1.2.1191\",\"using_owner_authority\":true,\"proposal\":\"1.10.48\",\"extensions\":[]}]],\"extensions\":[],\"signatures\":[\"20092147f99b4596202d2cafa54aa81e7a5330fb6adc5c7f3484f4e4f4b75e32132cc4bad1637d7a71a476feef30ac320418e0ff7e98cbf6750770d38257d06741\"]}}\n th_a db_block.cpp:220 push_transaction","data":{"id":184,"error":{"code":1,"message":"10 assert_exception: Assert Exception\nrequired_approvals->find(o.fee_paying_account) != required_approvals->end(): Provided authority is not authoritative for this proposal.\n {\"provided\":\"1.2.1191\",\"required\":[]}\n th_a proposal_evaluator.cpp:196 do_evaluate\n\n {\"o\":{\"fee\":{\"amount\":200000,\"asset_id\":\"1.3.0\"},\"fee_paying_account\":\"1.2.1191\",\"using_owner_authority\":true,\"proposal\":\"1.10.48\",\"extensions\":[]}}\n th_a proposal_evaluator.cpp:199 do_evaluate\n\n {}\n th_a evaluator.cpp:46 start_evaluate\n\n {}\n th_a db_block.cpp:653 apply_operation\n\n {\"trx\":{\"ref_block_num\":6939,\"ref_block_prefix\":4113412531,\"expiration\":\"2016-01-09T01:59:42\",\"operations\":[[24,{\"fee\":{\"amount\":200000,\"asset_id\":\"1.3.0\"},\"fee_paying_account\":\"1.2.1191\",\"using_owner_authority\":true,\"proposal\":\"1.10.48\",\"extensions\":[]}]],\"extensions\":[],\"signatures\":[\"20092147f99b4596202d2cafa54aa81e7a5330fb6adc5c7f3484f4e4f4b75e32132cc4bad1637d7a71a476feef30ac320418e0ff7e98cbf6750770d38257d06741\"]}}\n th_a db_block.cpp:636 _apply_transaction\n\n {\"trx\":{\"ref_block_num\":6939,\"ref_block_prefix\":4113412531,\"expiration\":\"2016-01-09T01:59:42\",\"operations\":[[24,{\"fee\":{\"amount\":200000,\"asset_id\":\"1.3.0\"},\"fee_paying_account\":\"1.2.1191\",\"using_owner_authority\":true,\"proposal\":\"1.10.48\",\"extensions\":[]}]],\"extensions\":[],\"signatures\":[\"20092147f99b4596202d2cafa54aa81e7a5330fb6adc5c7f3484f4e4f4b75e32132cc4bad1637d7a71a476feef30ac320418e0ff7e98cbf6750770d38257d06741\"]}}\n th_a db_block.cpp:220 push_transaction","data":{"code":10,"name":"assert_exception","message":"Assert Exception","stack":[{"context":{"level":"error","file":"proposal_evaluator.cpp","line":196,"method":"do_evaluate","hostname":"","thread_name":"th_a","timestamp":"2016-01-09T01:59:14"},"format":"required_approvals->find(o.fee_paying_account) != required_approvals->end(): Provided authority is not authoritative for this proposal.","data":{"provided":"1.2.1191","required":[]}},{"context":{"level":"warn","file":"proposal_evaluator.cpp","line":199,"method":"do_evaluate","hostname":"","thread_name":"th_a","timestamp":"2016-01-09T01:59:14"},"format":"","data":{"o":{"fee":{"amount":200000,"asset_id":"1.3.0"},"fee_paying_account":"1.2.1191","using_owner_authority":true,"proposal":"1.10.48","extensions":[]}}},{"context":{"level":"warn","file":"evaluator.cpp","line":46,"method":"start_evaluate","hostname":"","thread_name":"th_a","timestamp":"2016-01-09T01:59:14"},"format":"","data":{}},{"context":{"level":"warn","file":"db_block.cpp","line":653,"method":"apply_operation","hostname":"","thread_name":"th_a","timestamp":"2016-01-09T01:59:14"},"format":"","data":{}},{"context":{"level":"warn","file":"db_block.cpp","line":636,"method":"_apply_transaction","hostname":"","thread_name":"th_a","timestamp":"2016-01-09T01:59:14"},"format":"","data":{"trx":{"ref_block_num":6939,"ref_block_prefix":4113412531,"expiration":"2016-01-09T01:59:42","operations":[[24,{"fee":{"amount":200000,"asset_id":"1.3.0"},"fee_paying_account":"1.2.1191","using_owner_authority":true,"proposal":"1.10.48","extensions":[]}]],"extensions":[],"signatures":["20092147f99b4596202d2cafa54aa81e7a5330fb6adc5c7f3484f4e4f4b75e32132cc4bad1637d7a71a476feef30ac320418e0ff7e98cbf6750770d38257d06741"]}}},{"context":{"level":"warn","file":"db_block.cpp","line":220,"method":"push_transaction","hostname":"","thread_name":"th_a","timestamp":"2016-01-09T01:59:14"},"format":"","data":{"trx":{"ref_block_num":6939,"ref_block_prefix":4113412531,"expiration":"2016-01-09T01:59:42","operations":[[24,{"fee":{"amount":200000,"asset_id":"1.3.0"},"fee_paying_account":"1.2.1191","using_owner_authority":true,"proposal":"1.10.48","extensions":[]}]],"extensions":[],"signatures":["20092147f99b4596202d2cafa54aa81e7a5330fb6adc5c7f3484f4e4f4b75e32132cc4bad1637d7a71a476feef30ac320418e0ff7e98cbf6750770d38257d06741"]}}}]}}}}
th_a state.cpp:38 handle_reply
unlocked >>>
[code]
I have tried changing a couple of the options within the transaction, still fails. Any idea what I am doing wrong?
-
Hmm.. @puppies you may need to set "using_owner_authority" to false, as the committee-account has no owner authority but only active authority: http://cryptofresh.com/u/committee-account
committee-account 1.2.0
Owner none
Active Multisig Auth
A little off-topic: looks like this proposal_delete_operation isn't well designed. By this way a "bad" committee member is able to prevent anything from happening. Maybe some misunderstanding here..
This operation allows the early veto of a proposed transaction. It may be used by any account which is a required authority on the proposed transaction, when that account's holder feels the proposal is ill-advised and he decides he will never approve of it and wishes to put an end to all discussion of the issue.
-
I get the same error with the false flag on owner authority.
Also anyone abusing the transaction would need to be voted out.
-
I get the same error with the false flag on owner authority.
Also anyone abusing the transaction would need to be voted out.
Can you post here the whole error message when the flag is false? I think it should be different at least this line:
{"provided":"1.2.1191","required":[]}
-
Yeah. I'm at dinner with the wife. I'll post later.
-
Yeah. I'm at dinner with the wife. I'll post later.
I just tried by myself. ;)
{
"ref_block_num": 8845,
"ref_block_prefix": 4171956341,
"expiration": "2016-01-09T03:35:18",
"operations": [[
24,{
"fee": {
"amount": 200000,
"asset_id": "1.3.0"
},
"fee_paying_account": "1.2.12376",
"using_owner_authority": false,
"proposal": "1.10.48",
"extensions": []
}
]
],
"extensions": [],
"signatures": [
"1f4b0fc547dcfd8629a3cfe520d6338ce231399af409abe3df538c97f91e915550391098eeeea075c922acad5dccd3a3c64fd4ebb0e3f26ed248ee9f728c23514
1"
]
}
10 assert_exception: Assert Exception
required_approvals->find(o.fee_paying_account) != required_approvals->end(): Provided authority is not authoritative for this proposal.
{"provided":"1.2.12376","required":["1.2.0"]}
//Edit:
So it doesn't recursively check the authorities in case when multi-sig authority involved. A bug?
Imo it's better to set a threshold equals to (total_weight - approve_threshold) for proposal_delete_operation, so the proposal will only be deleted if enough authorities agree to delete the proposal.
//Edit2:
I submitted an issue to github: https://github.com/cryptonomex/graphene/issues/515
-
what I get is
unlocked >>> sign_builder_transaction 0 true
sign_builder_transaction 0 true
3468578ms th_a wallet.cpp:1919 sign_transaction ] Caught exception while broadcasting tx 9e1369d210581e5622950658aa75f791d226ac61: 0 exception: unspecified
10 assert_exception: Assert Exception
required_approvals->find(o.fee_paying_account) != required_approvals->end(): Provided authority is not authoritative for this proposal.
{"provided":"1.2.1191","required":["1.2.0"]}
th_a proposal_evaluator.cpp:196 do_evaluate
{"o":{"fee":{"amount":200000,"asset_id":"1.3.0"},"fee_paying_account":"1.2.1191","using_owner_authority":false,"proposal":"1.10.48","extensions":[]}}
th_a proposal_evaluator.cpp:199 do_evaluate
{}
th_a evaluator.cpp:46 start_evaluate
{}
th_a db_block.cpp:653 apply_operation
{"trx":{"ref_block_num":9305,"ref_block_prefix":2804019475,"expiration":"2016-01-09T03:58:18","operations":[[24,{"fee":{"amount":200000,"asset_id":"1.3.0"},"fee_paying_account":"1.2.1191","using_owner_authority":false,"proposal":"1.10.48","extensions":[]}],[24,{"fee":{"amount":0,"asset_id":"1.3.0"},"fee_paying_account":"1.2.1191","using_owner_authority":false,"proposal":"1.10.48","extensions":[]}]],"extensions":[],"signatures":["1f066d3b3cafac0b51a8dacc8a1abb347ed681d990ada29ae4430f88946f6f1391666615a46546877f0f18b1d439cd16392c6a8451d6768d8e6412efdd73fc895a"]}}
th_a db_block.cpp:636 _apply_transaction
{"trx":{"ref_block_num":9305,"ref_block_prefix":2804019475,"expiration":"2016-01-09T03:58:18","operations":[[24,{"fee":{"amount":200000,"asset_id":"1.3.0"},"fee_paying_account":"1.2.1191","using_owner_authority":false,"proposal":"1.10.48","extensions":[]}],[24,{"fee":{"amount":0,"asset_id":"1.3.0"},"fee_paying_account":"1.2.1191","using_owner_authority":false,"proposal":"1.10.48","extensions":[]}]],"extensions":[],"signatures":["1f066d3b3cafac0b51a8dacc8a1abb347ed681d990ada29ae4430f88946f6f1391666615a46546877f0f18b1d439cd16392c6a8451d6768d8e6412efdd73fc895a"]}}
th_a db_block.cpp:220 push_transaction
{"error":"10 assert_exception: Assert Exception\nrequired_approvals->find(o.fee_paying_account) != required_approvals->end(): Provided authority is not authoritative for this proposal.\n {\"provided\":\"1.2.1191\",\"required\":[\"1.2.0\"]}\n th_a proposal_evaluator.cpp:196 do_evaluate\n\n {\"o\":{\"fee\":{\"amount\":200000,\"asset_id\":\"1.3.0\"},\"fee_paying_account\":\"1.2.1191\",\"using_owner_authority\":false,\"proposal\":\"1.10.48\",\"extensions\":[]}}\n th_a proposal_evaluator.cpp:199 do_evaluate\n\n {}\n th_a evaluator.cpp:46 start_evaluate\n\n {}\n th_a db_block.cpp:653 apply_operation\n\n {\"trx\":{\"ref_block_num\":9305,\"ref_block_prefix\":2804019475,\"expiration\":\"2016-01-09T03:58:18\",\"operations\":[[24,{\"fee\":{\"amount\":200000,\"asset_id\":\"1.3.0\"},\"fee_paying_account\":\"1.2.1191\",\"using_owner_authority\":false,\"proposal\":\"1.10.48\",\"extensions\":[]}],[24,{\"fee\":{\"amount\":0,\"asset_id\":\"1.3.0\"},\"fee_paying_account\":\"1.2.1191\",\"using_owner_authority\":false,\"proposal\":\"1.10.48\",\"extensions\":[]}]],\"extensions\":[],\"signatures\":[\"1f066d3b3cafac0b51a8dacc8a1abb347ed681d990ada29ae4430f88946f6f1391666615a46546877f0f18b1d439cd16392c6a8451d6768d8e6412efdd73fc895a\"]}}\n th_a db_block.cpp:636 _apply_transaction\n\n {\"trx\":{\"ref_block_num\":9305,\"ref_block_prefix\":2804019475,\"expiration\":\"2016-01-09T03:58:18\",\"operations\":[[24,{\"fee\":{\"amount\":200000,\"asset_id\":\"1.3.0\"},\"fee_paying_account\":\"1.2.1191\",\"using_owner_authority\":false,\"proposal\":\"1.10.48\",\"extensions\":[]}],[24,{\"fee\":{\"amount\":0,\"asset_id\":\"1.3.0\"},\"fee_paying_account\":\"1.2.1191\",\"using_owner_authority\":false,\"proposal\":\"1.10.48\",\"extensions\":[]}]],\"extensions\":[],\"signatures\":[\"1f066d3b3cafac0b51a8dacc8a1abb347ed681d990ada29ae4430f88946f6f1391666615a46546877f0f18b1d439cd16392c6a8451d6768d8e6412efdd73fc895a\"]}}\n th_a db_block.cpp:220 push_transaction","data":{"id":187,"error":{"code":1,"message":"10 assert_exception: Assert Exception\nrequired_approvals->find(o.fee_paying_account) != required_approvals->end(): Provided authority is not authoritative for this proposal.\n {\"provided\":\"1.2.1191\",\"required\":[\"1.2.0\"]}\n th_a proposal_evaluator.cpp:196 do_evaluate\n\n {\"o\":{\"fee\":{\"amount\":200000,\"asset_id\":\"1.3.0\"},\"fee_paying_account\":\"1.2.1191\",\"using_owner_authority\":false,\"proposal\":\"1.10.48\",\"extensions\":[]}}\n th_a proposal_evaluator.cpp:199 do_evaluate\n\n {}\n th_a evaluator.cpp:46 start_evaluate\n\n {}\n th_a db_block.cpp:653 apply_operation\n\n {\"trx\":{\"ref_block_num\":9305,\"ref_block_prefix\":2804019475,\"expiration\":\"2016-01-09T03:58:18\",\"operations\":[[24,{\"fee\":{\"amount\":200000,\"asset_id\":\"1.3.0\"},\"fee_paying_account\":\"1.2.1191\",\"using_owner_authority\":false,\"proposal\":\"1.10.48\",\"extensions\":[]}],[24,{\"fee\":{\"amount\":0,\"asset_id\":\"1.3.0\"},\"fee_paying_account\":\"1.2.1191\",\"using_owner_authority\":false,\"proposal\":\"1.10.48\",\"extensions\":[]}]],\"extensions\":[],\"signatures\":[\"1f066d3b3cafac0b51a8dacc8a1abb347ed681d990ada29ae4430f88946f6f1391666615a46546877f0f18b1d439cd16392c6a8451d6768d8e6412efdd73fc895a\"]}}\n th_a db_block.cpp:636 _apply_transaction\n\n {\"trx\":{\"ref_block_num\":9305,\"ref_block_prefix\":2804019475,\"expiration\":\"2016-01-09T03:58:18\",\"operations\":[[24,{\"fee\":{\"amount\":200000,\"asset_id\":\"1.3.0\"},\"fee_paying_account\":\"1.2.1191\",\"using_owner_authority\":false,\"proposal\":\"1.10.48\",\"extensions\":[]}],[24,{\"fee\":{\"amount\":0,\"asset_id\":\"1.3.0\"},\"fee_paying_account\":\"1.2.1191\",\"using_owner_authority\":false,\"proposal\":\"1.10.48\",\"extensions\":[]}]],\"extensions\":[],\"signatures\":[\"1f066d3b3cafac0b51a8dacc8a1abb347ed681d990ada29ae4430f88946f6f1391666615a46546877f0f18b1d439cd16392c6a8451d6768d8e6412efdd73fc895a\"]}}\n th_a db_block.cpp:220 push_transaction","data":{"code":10,"name":"assert_exception","message":"Assert Exception","stack":[{"context":{"level":"error","file":"proposal_evaluator.cpp","line":196,"method":"do_evaluate","hostname":"","thread_name":"th_a","timestamp":"2016-01-09T03:57:48"},"format":"required_approvals->find(o.fee_paying_account) != required_approvals->end(): Provided authority is not authoritative for this proposal.","data":{"provided":"1.2.1191","required":["1.2.0"]}},{"context":{"level":"warn","file":"proposal_evaluator.cpp","line":199,"method":"do_evaluate","hostname":"","thread_name":"th_a","timestamp":"2016-01-09T03:57:48"},"format":"","data":{"o":{"fee":{"amount":200000,"asset_id":"1.3.0"},"fee_paying_account":"1.2.1191","using_owner_authority":false,"proposal":"1.10.48","extensions":[]}}},{"context":{"level":"warn","file":"evaluator.cpp","line":46,"method":"start_evaluate","hostname":"","thread_name":"th_a","timestamp":"2016-01-09T03:57:48"},"format":"","data":{}},{"context":{"level":"warn","file":"db_block.cpp","line":653,"method":"apply_operation","hostname":"","thread_name":"th_a","timestamp":"2016-01-09T03:57:48"},"format":"","data":{}},{"context":{"level":"warn","file":"db_block.cpp","line":636,"method":"_apply_transaction","hostname":"","thread_name":"th_a","timestamp":"2016-01-09T03:57:48"},"format":"","data":{"trx":{"ref_block_num":9305,"ref_block_prefix":2804019475,"expiration":"2016-01-09T03:58:18","operations":[[24,{"fee":{"amount":200000,"asset_id":"1.3.0"},"fee_paying_account":"1.2.1191","using_owner_authority":false,"proposal":"1.10.48","extensions":[]}],[24,{"fee":{"amount":0,"asset_id":"1.3.0"},"fee_paying_account":"1.2.1191","using_owner_authority":false,"proposal":"1.10.48","extensions":[]}]],"extensions":[],"signatures":["1f066d3b3cafac0b51a8dacc8a1abb347ed681d990ada29ae4430f88946f6f1391666615a46546877f0f18b1d439cd16392c6a8451d6768d8e6412efdd73fc895a"]}}},{"context":{"level":"warn","file":"db_block.cpp","line":220,"method":"push_transaction","hostname":"","thread_name":"th_a","timestamp":"2016-01-09T03:57:48"},"format":"","data":{"trx":{"ref_block_num":9305,"ref_block_prefix":2804019475,"expiration":"2016-01-09T03:58:18","operations":[[24,{"fee":{"amount":200000,"asset_id":"1.3.0"},"fee_paying_account":"1.2.1191","using_owner_authority":false,"proposal":"1.10.48","extensions":[]}],[24,{"fee":{"amount":0,"asset_id":"1.3.0"},"fee_paying_account":"1.2.1191","using_owner_authority":false,"proposal":"1.10.48","extensions":[]}]],"extensions":[],"signatures":["1f066d3b3cafac0b51a8dacc8a1abb347ed681d990ada29ae4430f88946f6f1391666615a46546877f0f18b1d439cd16392c6a8451d6768d8e6412efdd73fc895a"]}}}]}}}}
th_a state.cpp:38 handle_reply
0 exception: unspecified
10 assert_exception: Assert Exception
required_approvals->find(o.fee_paying_account) != required_approvals->end(): Provided authority is not authoritative for this proposal.
{"provided":"1.2.1191","required":["1.2.0"]}
th_a proposal_evaluator.cpp:196 do_evaluate
{"o":{"fee":{"amount":200000,"asset_id":"1.3.0"},"fee_paying_account":"1.2.1191","using_owner_authority":false,"proposal":"1.10.48","extensions":[]}}
th_a proposal_evaluator.cpp:199 do_evaluate
{}
th_a evaluator.cpp:46 start_evaluate
{}
th_a db_block.cpp:653 apply_operation
{"trx":{"ref_block_num":9305,"ref_block_prefix":2804019475,"expiration":"2016-01-09T03:58:18","operations":[[24,{"fee":{"amount":200000,"asset_id":"1.3.0"},"fee_paying_account":"1.2.1191","using_owner_authority":false,"proposal":"1.10.48","extensions":[]}],[24,{"fee":{"amount":0,"asset_id":"1.3.0"},"fee_paying_account":"1.2.1191","using_owner_authority":false,"proposal":"1.10.48","extensions":[]}]],"extensions":[],"signatures":["1f066d3b3cafac0b51a8dacc8a1abb347ed681d990ada29ae4430f88946f6f1391666615a46546877f0f18b1d439cd16392c6a8451d6768d8e6412efdd73fc895a"]}}
th_a db_block.cpp:636 _apply_transaction
{"trx":{"ref_block_num":9305,"ref_block_prefix":2804019475,"expiration":"2016-01-09T03:58:18","operations":[[24,{"fee":{"amount":200000,"asset_id":"1.3.0"},"fee_paying_account":"1.2.1191","using_owner_authority":false,"proposal":"1.10.48","extensions":[]}],[24,{"fee":{"amount":0,"asset_id":"1.3.0"},"fee_paying_account":"1.2.1191","using_owner_authority":false,"proposal":"1.10.48","extensions":[]}]],"extensions":[],"signatures":["1f066d3b3cafac0b51a8dacc8a1abb347ed681d990ada29ae4430f88946f6f1391666615a46546877f0f18b1d439cd16392c6a8451d6768d8e6412efdd73fc895a"]}}
th_a db_block.cpp:220 push_transaction
{"error":"10 assert_exception: Assert Exception\nrequired_approvals->find(o.fee_paying_account) != required_approvals->end(): Provided authority is not authoritative for this proposal.\n {\"provided\":\"1.2.1191\",\"required\":[\"1.2.0\"]}\n th_a proposal_evaluator.cpp:196 do_evaluate\n\n {\"o\":{\"fee\":{\"amount\":200000,\"asset_id\":\"1.3.0\"},\"fee_paying_account\":\"1.2.1191\",\"using_owner_authority\":false,\"proposal\":\"1.10.48\",\"extensions\":[]}}\n th_a proposal_evaluator.cpp:199 do_evaluate\n\n {}\n th_a evaluator.cpp:46 start_evaluate\n\n {}\n th_a db_block.cpp:653 apply_operation\n\n {\"trx\":{\"ref_block_num\":9305,\"ref_block_prefix\":2804019475,\"expiration\":\"2016-01-09T03:58:18\",\"operations\":[[24,{\"fee\":{\"amount\":200000,\"asset_id\":\"1.3.0\"},\"fee_paying_account\":\"1.2.1191\",\"using_owner_authority\":false,\"proposal\":\"1.10.48\",\"extensions\":[]}],[24,{\"fee\":{\"amount\":0,\"asset_id\":\"1.3.0\"},\"fee_paying_account\":\"1.2.1191\",\"using_owner_authority\":false,\"proposal\":\"1.10.48\",\"extensions\":[]}]],\"extensions\":[],\"signatures\":[\"1f066d3b3cafac0b51a8dacc8a1abb347ed681d990ada29ae4430f88946f6f1391666615a46546877f0f18b1d439cd16392c6a8451d6768d8e6412efdd73fc895a\"]}}\n th_a db_block.cpp:636 _apply_transaction\n\n {\"trx\":{\"ref_block_num\":9305,\"ref_block_prefix\":2804019475,\"expiration\":\"2016-01-09T03:58:18\",\"operations\":[[24,{\"fee\":{\"amount\":200000,\"asset_id\":\"1.3.0\"},\"fee_paying_account\":\"1.2.1191\",\"using_owner_authority\":false,\"proposal\":\"1.10.48\",\"extensions\":[]}],[24,{\"fee\":{\"amount\":0,\"asset_id\":\"1.3.0\"},\"fee_paying_account\":\"1.2.1191\",\"using_owner_authority\":false,\"proposal\":\"1.10.48\",\"extensions\":[]}]],\"extensions\":[],\"signatures\":[\"1f066d3b3cafac0b51a8dacc8a1abb347ed681d990ada29ae4430f88946f6f1391666615a46546877f0f18b1d439cd16392c6a8451d6768d8e6412efdd73fc895a\"]}}\n th_a db_block.cpp:220 push_transaction","data":{"id":187,"error":{"code":1,"message":"10 assert_exception: Assert Exception\nrequired_approvals->find(o.fee_paying_account) != required_approvals->end(): Provided authority is not authoritative for this proposal.\n {\"provided\":\"1.2.1191\",\"required\":[\"1.2.0\"]}\n th_a proposal_evaluator.cpp:196 do_evaluate\n\n {\"o\":{\"fee\":{\"amount\":200000,\"asset_id\":\"1.3.0\"},\"fee_paying_account\":\"1.2.1191\",\"using_owner_authority\":false,\"proposal\":\"1.10.48\",\"extensions\":[]}}\n th_a proposal_evaluator.cpp:199 do_evaluate\n\n {}\n th_a evaluator.cpp:46 start_evaluate\n\n {}\n th_a db_block.cpp:653 apply_operation\n\n {\"trx\":{\"ref_block_num\":9305,\"ref_block_prefix\":2804019475,\"expiration\":\"2016-01-09T03:58:18\",\"operations\":[[24,{\"fee\":{\"amount\":200000,\"asset_id\":\"1.3.0\"},\"fee_paying_account\":\"1.2.1191\",\"using_owner_authority\":false,\"proposal\":\"1.10.48\",\"extensions\":[]}],[24,{\"fee\":{\"amount\":0,\"asset_id\":\"1.3.0\"},\"fee_paying_account\":\"1.2.1191\",\"using_owner_authority\":false,\"proposal\":\"1.10.48\",\"extensions\":[]}]],\"extensions\":[],\"signatures\":[\"1f066d3b3cafac0b51a8dacc8a1abb347ed681d990ada29ae4430f88946f6f1391666615a46546877f0f18b1d439cd16392c6a8451d6768d8e6412efdd73fc895a\"]}}\n th_a db_block.cpp:636 _apply_transaction\n\n {\"trx\":{\"ref_block_num\":9305,\"ref_block_prefix\":2804019475,\"expiration\":\"2016-01-09T03:58:18\",\"operations\":[[24,{\"fee\":{\"amount\":200000,\"asset_id\":\"1.3.0\"},\"fee_paying_account\":\"1.2.1191\",\"using_owner_authority\":false,\"proposal\":\"1.10.48\",\"extensions\":[]}],[24,{\"fee\":{\"amount\":0,\"asset_id\":\"1.3.0\"},\"fee_paying_account\":\"1.2.1191\",\"using_owner_authority\":false,\"proposal\":\"1.10.48\",\"extensions\":[]}]],\"extensions\":[],\"signatures\":[\"1f066d3b3cafac0b51a8dacc8a1abb347ed681d990ada29ae4430f88946f6f1391666615a46546877f0f18b1d439cd16392c6a8451d6768d8e6412efdd73fc895a\"]}}\n th_a db_block.cpp:220 push_transaction","data":{"code":10,"name":"assert_exception","message":"Assert Exception","stack":[{"context":{"level":"error","file":"proposal_evaluator.cpp","line":196,"method":"do_evaluate","hostname":"","thread_name":"th_a","timestamp":"2016-01-09T03:57:48"},"format":"required_approvals->find(o.fee_paying_account) != required_approvals->end(): Provided authority is not authoritative for this proposal.","data":{"provided":"1.2.1191","required":["1.2.0"]}},{"context":{"level":"warn","file":"proposal_evaluator.cpp","line":199,"method":"do_evaluate","hostname":"","thread_name":"th_a","timestamp":"2016-01-09T03:57:48"},"format":"","data":{"o":{"fee":{"amount":200000,"asset_id":"1.3.0"},"fee_paying_account":"1.2.1191","using_owner_authority":false,"proposal":"1.10.48","extensions":[]}}},{"context":{"level":"warn","file":"evaluator.cpp","line":46,"method":"start_evaluate","hostname":"","thread_name":"th_a","timestamp":"2016-01-09T03:57:48"},"format":"","data":{}},{"context":{"level":"warn","file":"db_block.cpp","line":653,"method":"apply_operation","hostname":"","thread_name":"th_a","timestamp":"2016-01-09T03:57:48"},"format":"","data":{}},{"context":{"level":"warn","file":"db_block.cpp","line":636,"method":"_apply_transaction","hostname":"","thread_name":"th_a","timestamp":"2016-01-09T03:57:48"},"format":"","data":{"trx":{"ref_block_num":9305,"ref_block_prefix":2804019475,"expiration":"2016-01-09T03:58:18","operations":[[24,{"fee":{"amount":200000,"asset_id":"1.3.0"},"fee_paying_account":"1.2.1191","using_owner_authority":false,"proposal":"1.10.48","extensions":[]}],[24,{"fee":{"amount":0,"asset_id":"1.3.0"},"fee_paying_account":"1.2.1191","using_owner_authority":false,"proposal":"1.10.48","extensions":[]}]],"extensions":[],"signatures":["1f066d3b3cafac0b51a8dacc8a1abb347ed681d990ada29ae4430f88946f6f1391666615a46546877f0f18b1d439cd16392c6a8451d6768d8e6412efdd73fc895a"]}}},{"context":{"level":"warn","file":"db_block.cpp","line":220,"method":"push_transaction","hostname":"","thread_name":"th_a","timestamp":"2016-01-09T03:57:48"},"format":"","data":{"trx":{"ref_block_num":9305,"ref_block_prefix":2804019475,"expiration":"2016-01-09T03:58:18","operations":[[24,{"fee":{"amount":200000,"asset_id":"1.3.0"},"fee_paying_account":"1.2.1191","using_owner_authority":false,"proposal":"1.10.48","extensions":[]}],[24,{"fee":{"amount":0,"asset_id":"1.3.0"},"fee_paying_account":"1.2.1191","using_owner_authority":false,"proposal":"1.10.48","extensions":[]}]],"extensions":[],"signatures":["1f066d3b3cafac0b51a8dacc8a1abb347ed681d990ada29ae4430f88946f6f1391666615a46546877f0f18b1d439cd16392c6a8451d6768d8e6412efdd73fc895a"]}}}]}}}}
th_a state.cpp:38 handle_reply
unlocked >>>
when I try to use 1.2.0 as the authority it also fails. Then it has
3030006 invalid_committee_approval: committee account cannot directly approve transaction
Committee account may only propose transactions
-
So where does this stand now? Any agreement reached?
-
So where does this stand now? Any agreement reached?
Some fund will be get out from the accumulated fee pool and deposit to committee-account, after 8 hours. The amout is around 7000$.
No other agreement reached.
-
So where does this stand now? Any agreement reached?
Good questions akado. Thanks to the committee for being open and helping answer questions.
-
So where does this stand now? Any agreement reached?
Some fund will be get out from the accumulated fee pool and deposit to committee-account, after 8 hours. The amout is around 7000$.
No other agreement reached.
Oh sorry, I was searching on worker proposals and didn't find that's why I found it strange. @rgcrypto maybe a page showing both worker and committee proposals and a tab for each would be easier, it's confusing I need to scroll down and didn't know about it, no info regarding committee proposals on the nav bar.
@abit I believe the review period starts in 7 hours. So in 7 hours the funds won't be moved but voting will start?
http://cryptofresh.com/p/1.10.49
-
So where does this stand now? Any agreement reached?
Some fund will be get out from the accumulated fee pool and deposit to committee-account, after 8 hours. The amout is around 7000$.
No other agreement reached.
Oh sorry, I was searching on worker proposals and didn't find that's why I found it strange. @rgcrypto maybe a page showing both worker and committee proposals and a tab for each would be easier, it's confusing I need to scroll down and didn't know about it, no info regarding committee proposals on the nav bar.
@abit I believe the review period starts in 7 hours. So in 7 hours the funds won't be moved but voting will start?
http://cryptofresh.com/p/1.10.48
That proposal was not done right.. a new one was created afterwards.. which you can see has been supported:
http://cryptofresh.com/p/1.10.49
-
Thanks I edited the post to avoid confusion
-
is there a way to get a list quickly of who has posted to a thread?