@Cityglut. In the event the hacker turns blackhat and peaces out.. what does the future hold ? Shouldn't we resume the show ?
 We personally have offered the hacker 12 BTC, and others have stepped up and sent 700 XCP to our bug bounty program. I would strongly encourage the community not to wait for something that is out of our control, but to proactive and either donate directly to busoni's donation address: < 15buRLRW47AY9Md3mpFj17Yp6w4BtfMRjc> or our "bug bounty" donation address < 14Tf35AovvRVURzd623q5i9kry2EW8WzyL> I am not sure what you mean when you ask "what does the future hold ? Shouldn't we resume the show ?" Recent events have not stopped us from working on Counterparty: yesterday we paid out the desktop GUI bounty, xnova's web wallet will be released in beta on testnet with a week, the centralized exchange bounty will end in a few days, and the official website will be getting a major upgrade in the next few weeks. |
|
|
|
xnova, phantomphreak, busoni ? anything at all ? any input any tidbits ?
We are looking at the forums, and understand that people would like an update, but it is still the case that we have heard nothing from the hacker in over 24 hours. When we get an update we will give it to the community, however, until we hea from the hacker, there is no update to give. |
|
|
|
The GUI doesn't work.
On Win XP (32bit) it said missing file msvcr100.dll
On Win 7 (64 bit) python.exe crash
For the msvcr100.dll error , this is due to the need for Visual Studio run time. You can install both the 32/64 bit versions of runtime from here. http://www.faqforge.com/windows/fix-the-program-cant-start-because-msvcr100-dll-is-missing-from-your-computer-error-on-windows/I was able to get past this error, using this. However, I am still stuck with the GUI. Clicking "Start the Party" brings up the config Window. Click OK. Click "Open Wallet" , Receive "Error message: you did not start the party". Are there any other components that need to be installed? Make sure you have entered a "gui password" in the configuration file. This is the only part of the config file that is not automatically filled in, and it is easy to miss.  |
|
|
|
I know you mean well and recovering the XCP would be good for the community at large.
There is no reason to think that these users knew that there was something malicious going on when they took their gains.
Allow the users to make the choice themselves without being coerced.
I don't think any user knew that there was something malicious going on when they took their gains (I myself bought some xcp @ 0.002) but now we do know exactly what happened. If i understand what you are saying than why don't allow all of poloniex users to make the choice for themselves and don't rollback? the answer is simple in my opinion - if we can get everything back to where it was before the 35,000 xcp sell that will be the best thing for all users. For clarification i don't think any treats should be used i just think it will be helpful if we knew who we need to speak to in order to get this situation behind us asap. I totally agree. I just don't want people getitng the wrong ideas Yes why dont roll back the database to before the dump so the 6100 outstanding XCP are back to where they legitimately belong? (given busoni restores the BTC balances of those that withdrew their 6100 XCP after the dump because they would be out of BTC and XCP) Which database are you talking about--Poloniex's or Counterparty's? Im talking about the Counterparty Database. I guess the first attempt to roll back was well intended but was just a bit off by a few minutes with rolling back up until after the dump because the situation was not clear and a community consensus missing (still is). So by rolling back up until before the dump all the outstanding XCP will be back in their original holders pockets at Poloniex (sorry guys but the cheap XCP you withdrew are not meant to be yours) and if you busoni, refill the BTC balances of the users that withdrew their cheap XCP, everybody will be made whole again, as far as we can have an effect on it. Only the hacker's BTC would be outstanding in that case which he already pledged to return. We cannot roll back BTC transactions, so what you are suggesting would require busoni to personally pay out-of-pocket for people's losses, i.e. around 100 BTC. We hope that the hacker will do the right thing, but we cannot base our actions on that hope; we can only act "as if" the hacker has returned the BTC when he has returned the BTC. Until then, those who want to help make things right are encouraged either to donate to our "security bug" address: 14Tf35AovvRVURzd623q5i9kry2EW8WzyL or to busoni's donation address: 15buRLRW47AY9Md3mpFj17Yp6w4BtfMRjc. |
|
|
|
Has anybody created GoxBTC -> RealBTC listing on DEX?
Maybe someone can take advantage. market is ripe for it.
Actually, those who have their money on Mt. Gox could have made a BearCFD in order to hedge against the price on Mt. Gox decreasing. Of course, this would have required someone who was "long" Mt. Gox, which would probably have been difficult. |
|
|
|
Announcement: Desktop GUI bounty funds to be distributed.The funds at the bounty address amount to: - 7.41790989 BTC
- 1856.13963636 XCP
There were two submissions for the "desktop GUI" bounty - one from JahPowerBit, and one from btcfanatic. Between these two users, funds at the bounty address will be split thus: - JahPowerBit will receive: 4.45074594 BTC and 1113.68378182 XCP
- btcfanatic will receive: 2.96716395 BTC and 742.45585454 XCP
In other words, JahPowerBit will receive 60% of the bounty funds, and btcfanatic will receive 40% of the bounty funds. JahPowerBit has demonstrated enthusiasm and initiative, and has made a functioning web GUI. He has also detailed his plans for the future, and has recruited other community members to help him achieve the goals he has set out. JahPowerBit's GUI has wider functionality than btcfanatic's, but btcfanatic's architecture was more what we had in mind. With that said, we imagine users will have a harder time getting btcfanatic's GUI to work than JahPowerBit's. While both GUIs are cross-platform, they lack build systems for Windows. Going forward, this is very important. We strongly encourage the community to get involved: test out the GUIs, interact and collaborate with the developers, and give them feedback. Counterparty is a community driven project, and will progress most effectively if the community works together. Thanks very much to both JahPowerBit and btcfanatic for participating in the Desktop GUI bounty, and helping the Counterparty protocol become more user-friendly. And thanks to the community for providing donations, to help motivate developers. We are discussing further bounties which should leverage what has been achieve with the desktop GUI bounty. Please stay tuned. btcfanatic and JahPowerBit, please email your addresses to < bounties@counterparty.co>. This is cross-posted from the bounty thread on the official Counterparty forums. EDIT: Of course, here are the GUI submissions:
|
|
|
|
|
The development team has extended a 12 BTC reward to the hacker for finding the security flaws, contingent upon returning the missing BTC. We are waiting to hear back.
We have offered these BTC out of our pockets, but, beyond that, we hope the community can pull together to make things right. As a reminder, the donation address for the security bouty is: <14Tf35AovvRVURzd623q5i9kry2EW8WzyL>.
What we do next depends on what the hacker does.
Regarding the discussion on a XCP "tax" or "re-burn", we can state this: The strength of Counterparty's community helps differentiate us from other projects, and it is precisely that strength which makes it clear it is best not to introduce a new burn period.
While the protocol will become more secure and robust as time goes on and our community grows, it is also the case that if there are serious bugs in the future, more people will be affected, and, as a project, Counterparty will have more to lose. Our decisions now will determine how the community evolves, and by demonstrating our collective firmness, we are setting important precedent for the future: those who invest in XCP are investing in a currency with a stable money supply, the integrity of which will be maintained even in difficult circumstances.
Take Bitcoin as an example: there have been times in Bitcoin's history where a serious bug could have been dealt with by, for example, increasing the total number of Bitcoins. If this had happened, would Bitcoin still be seen as an example of stable money supply and good store-of-value?
The seriousness of this bug should not be underplayed, but by taking our growing pains in their stride, we are strengthening Counterparty for the future.
|
|
|
|
As someone said before--do NOT buy XCP from anyone until this is fixed. Not on the DEX, not privately, not anywhere.
It sounds like the hacker is being cooperative, so probably a good guy and aligned with the success of the project and helping us to harden the code. To resolve the situation, maybe devs could offer to pay the hacker a 'security bounty' to reward him for isolating this vulnerability and because he's been cooperative / good guy, and also create a standing "security bounty" for anyone else in the wider community who finds exploits in the future. Yes. Setting up a formal bug bounty system is definitely on our 'to do' list. Cityglut, I know you have a lot on your plate, but when you have some time perhaps you can send out a wallet address for a security bounty fund? If it turns out the "roll back" is 100% retroactive (and I get all of my XCP back on Poloniex), I will happily contribute 100 XCP to the bounty fund to get it started. As a proposal for the community, perhaps we could send the first, say, [1000] XCP raised to the whitehat who exposed this exploit? Will anyone else make a pledge to contribute alongside me? A great idea. This will be taken care of in the next few hours. Thanks again, everyone, for all the support, and for staying level-headed. It means a lot to us. |
|
|
|
All,
I've been discussing with busoni who operates Poloniex the possibility of Poloniex basically issuing and underwriting the value of 1 XBTC = 1 BTC.
I have already issued 21M XBTC (divisible, non callable). It isn't locked because I'm getting an error locking it but this will be done prior to any sale of XBTC.
The idea is that Poloniex will create an service which will buy and sell XBTC to BTC at a fixed value of 1:1. The fee will be kept low + tx fees.
Pros
* Frictionless trading against XBTC
* More choice in the way the DEX is utilized
Cons
* Further centralized risk on Poloniex
If the idea goes forward, I'll transfer the asset to himself so there will be no more XBTC in circulation than what he sells.
How does everyone feel about this?
I'm going to attempt to instigate more feedback on this. I'll explain one big advantage of the above. If Poloniex proves to be trustworthy, then a XBTC will have and maintain the same buying power as a BTC. This means you can trade XCP for XBTC without using btcpay. You can totally avoid the troll orders because XCP and XBTC can be both held in escrow. This will hold true for any Counterparty asset vs BTC. This is a great idea! It's great to see such an excellent use of the protocol. Just so Poloniex can prepare for the worst: Even if he underwrites XBTC with BTC, it is possible that he could end up taking a loss (e.g. the price of XBTC plummets and it will be in his best interest to buy back XBTC below parity). I would strongly suggest that he make a CFD and short the price of XBTC to hedge against the devaluation of XBTC. In this case, if BTC/XBTC < 1, he can make up for it with profits from his CFD. led_lcd, I will PM you with some more details. |
|
|
|
That is a good, succinct representation of the protocol! Thank you! |
|
|
|
I don't see the reasoning behind an Asset Issuance based Currency Peg as opposed to a Feed Bet - The former requires trusting 'Bob' as the asset issuer, the later only a trusted feed.
In order for people to actually buy BOBUSD, Bob will most likely have to be not just be some guy, but, for example, the owner of a well-known BTC centralized exchange. There's something a tad ironic in this suggestion (given recent events). Of course there has to be a reciprocal betting party, but in the feed case, the bet is trustless and only the broadcast is dependent, where as with BOB (hopefully not Mark) the BTC Exchange owner, there are two components to the trust. On one hand this could lead to larger and more long term commitments (since betting amounts are escrowed, a large capital would be idle during the bet, whereas in the later case both BOB and the buyer are free to utilize the respective assets exchanged freely). As for callable/non-callable assets, still the risk on the non-callable is only in so far as an issuer is solvent for sum total value of all the assets/obligations. Hm, maybe I should change "Bob" to "Mark" so people are more aware of the risk involved... My point was not to downplay the trust issue, but rather to say that *if* the trust issue can be gotten over, then asset based currency pegs have some features that CFD currency pegs lack, and avoid some of the dependencies as well. |
|
|
|
That's great! I recommend that whoever issued GLDAEA [em]provide his issuing address on the website[/em], which will give some identity verification, and I recommend that users not purchase GLDAEA until the issuer has done so. |
|
|
|
I don't see the reasoning behind an Asset Issuance based Currency Peg as opposed to a Feed Bet - The former requires trusting 'Bob' as the asset issuer, the later only a trusted feed.
In order for people to actually buy BOBUSD, Bob will most likely have to be not just be some guy, but, for example, the owner of a well-known BTC centralized exchange. *If* Bob is trustworthy, then BOBUSD can be passed from user-to-user like a bank note, and hence could act a money replacement. There are also two contingencies with bets: 1. there has to be someone broadcasting the data you want to bet on; 2. there has to be someone willing to take the other side of your bet; the latter requires that they agree to your odds, your leverage and your deadline. Moreover with the CFD "currency peg", you are pegged against USD (for example) for, so to speak, a short time: what if the price of XCP dips again after your bet is over? Assuming the issuer is trustworthy, with an asset issuance based currency peg, you can maintain your peg for longer. Also, the degree to which you can cover your bet is proportional to your leverage, hence a more secure peg means greater risk. With asset issuance based currency pegs, the price you buy at is the price of your peg. Naturally, for the risk taken by the issuer, the latter will probably require a premium. Asset issuance based currency pegs, will, in my opinion, probably always be "callable" assets, as the risk is otherwise completely on the side of the issuer. |
|
|
|
Oh yes that'sa very common error. It means wait for the Web wallet. Ha kidding, looks like you need to reindex though.
I did already reindex to no avail unfortunately  You have testnet=1 in your bitcoin.conf file, but not in your counterpartyd.conf file. If you want to run counterpartyd on testnet, make sure both your .conf files have testnet=1, and if not, make sure neither do. EDIT: also, I believe the bitcoind-rpc-port should be 8332 not 18832, as you have it. |
|
|
|
So, if someone's order got stuck matched by this troll order, there is no way to get XCP back except to wait till the order expires as set by --expiration parameter? XCP will not be lost and get back to the owner again, not no quick way to get them back?
Yes (as set by the minimum of the expirations of the two matched orders). But that'll change with block 286500, after which only 10 blocks will ever be allowed for BTC payments to be made. Will this change at block 286500 release all currently stuck matched orders or will it be effective for new orders only? Why not make sellers of BTC escrow their BTC as well, just like sellers of XCP have to escrow? Is this technically impossible? At the very least, to check against their BTC balance before letting them place an order if BTC is actually available in their wallet. This doesn't stop them from making many small troll orders with small amounts, so escrow is still better if possible. It is technically impossible to escrow BTC. If someone doesn't want his order to be filled by a troll, he should raise his fee_required; the lower one's fee_required is, the cheaper it is for a troll to fill his order. |
|
|
|
XCP is not another altcoin. The key is to improve the Dex. Without a working reliable DEX, put it on more exchanges is just a pump and dump. It may make the early investors rich quickly, but never a real success. For those who have tens of thousands of XCP, I don't think you can liquidate all you holding by just pump and dump. A real DEX is a must.
I agree, its too early to list on a bunch of centralized exchanges, and that's really not the goal of the project anyways. +1 For the long term viability we need to help the devs come out with a user friendly wallet and DEX so that the entry barrier is lowered. Not everyone is comfortable with command line and it is not very idiot proof either. If the least we can do is test the system, then that' what we must do and pass on the feedback in a manner that is consumable by the devs. Secondly, there are stray enquirers by people who want to issue stocks, we must help these guys out. the more stocks that can be issued and sold on the platform means more people will automatically want XCP since they will need it to buy their preferred asset. In case members of the community are not aware, there were two participants in the GUI bounty, and their submissions can be found here: https://forums.counterparty.co/index.php/topic,8.0.html |
|
|
|
And done. It's in release 51, just pushed to google play and currently available here: http://lw.phauna.org/ Keep an eye on your XCP prices right along side your other faves edit: so as not to clutter this thread with any further OT chatter about my widget, please, all widget-related comments to this thread. This looks great! Thanks so much! |
|
|
|
what's the deal with the massive troll buy? http://blockscan.com/order.aspx?q=3594is there something being worked on to counteract this kind of stuff? Or at least make the tx fee proportional to btc sell offer for it to be valid? That has already been implemented: now fee_provided is a percentage of one's "BTC sell" purchase. |
|
|
|
|
Show Posts
