[ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread

[jl777]

Ok.So running xcp on top of an altcoin is possible. But is it possible to run xcp on an own blockchain and if so is that an option / planned?  

And would the GUI client allow an easy installation?

Not sure what you mean exactly by "counterparty with proof of stake on an own chain (or nxt or ppc)" ... https://counterparty.co/faqs/can-counterparty-work-on-blockchains-other-than-bitcoin/

Counterparty could probably work on a hybrid POS blockchain like PPC.... the key is really around being able to encode the data into both the POW blocks and the POS blocks. I'm not 100% certain of the state of PPC's multisig support (and it probably doesn't relay OP_RETURN currently, as that's just coming around for bitcoin itself). However, as long as we can do multisig into the blocks, then in concept counterparty could be made to work with a different Bitcoin-based blockchain. Note that there are other technical considerations that would need to be taken into account as well that could have an impact on the implementation, such as block timing.

With things like NXT, that's totally up in the air, as it's not based around Bitcoin. I don't know enough about it to say one way or the other. Probably just simpler for NXT to develop that kind of functionality natively.

With regards to your GUI question... that is the whole point of a web wallet, there *is* no installation. No counterpartyd to set up and install. You simply go to a webpage, generate a passphrase, paste it into a text box, and click login. Takes all of 5 seconds. Nothing to save or worry about beyond your pass phrase (which *is* your wallet)

@xnova
Assuming that there are no fundamental problems to port XCP to a whole series of altcoins, eg. LTC, NMC, DOGE, etc. it would seem to me that there could be a single counterpartyd that integrated all of them into a single daemon. Basically, it would scan the system and see which altcoind's are running and then enable the XCP for each one that exists.

Alternatively, separate executables installed by GUI and checkboxes. Anyway exact packaging is not what I care about. I just want to brainstorm possible future versions of XCP that we can get to with minimal effort from here to there, but have the most dramatic effect in value. This is needed to get XCP beyond the "what is its value compared to mastercoin" prices and into the "what is the value of XCP as compared to all the other altcoins combined" discussion!

OK, so now we have all these altXCP's in parallel and for each one it would be possible to do escrow of the XCP, but we need a ALT_pay command, just like we need BTC_pay command to complete the transaction. I dont see any reason why all the altXCP's cant be the real XCP, so there is a constant anchor in pricing XCP to all other crypto.

Now, let us imagine that we have a GUI or even at the protocol level which automatically does the BTC_pay when it detects that all the requirements for it are met. While, it would still be possible for only part of the transaction to happen and then later be unwound, I think the default behavior of end users is to accept the automated ALT_pay.

At this point, we would have an effectively automatic decentralized crypto/XCP exchange that doesnt require trust. The GUI guys will have to add support for all the additional assets and probably the same asset name under XCP.doge would NOT be fungible with the main XCP asset, but that is a small price to pay for fully automated cross chain DEX. I think this avoids any need for synchronizing the different chains, since the only synchronization is within each altXCP.

Did I make a mistake in the above?

James

P.S. It would be nice to have an efficient and low cost way of transferring XCP between all the different altXCP worlds, that would make it nearly perfect

[SyRenity]

With regards to your GUI question... that is the whole point of a web wallet, there *is* no installation. No counterpartyd to set up and install. You simply go to a webpage, generate a passphrase, paste it into a text box, and click login. Takes all of 5 seconds. Nothing to save or worry about beyond your pass phrase (which *is* your wallet)

This kinda reminds me of NXT - any chance we run into same security problems with that, as they did?

[jl777]

With regards to your GUI question... that is the whole point of a web wallet, there *is* no installation. No counterpartyd to set up and install. You simply go to a webpage, generate a passphrase, paste it into a text box, and click login. Takes all of 5 seconds. Nothing to save or worry about beyond your pass phrase (which *is* your wallet)

This kinda reminds me of NXT - any chance we run into same security problems with that, as they did?

Just need to have the (brain)wallet refuse or complain a LOT about low entropy passwords

[flatfly]

Despite a common misunderstanding, brainwallets per se are absolutely not insecure.  See Electrum's 12-word seed for an example of a secure implementation. What is insecure is a *human-chosen* passphrase/seed.  

[MoneypakTrader.com]

Orders match even the amount is lower than config.DUST_SIZE. If it's impossible to make the BTCPay, i think the orders should not match.

http://blockscan.com/order_match.aspx?q=3604

Agreed, something like suggestion 2 would work, right?
https://forums.counterparty.co/index.php/topic,71.msg321.html#msg321

But the other suggestions really come together to harden and improve the matching protocol don't they?
Why should a request to buy 1000 XCP match with a 0.005 XCP order or an order that expires in 2 bocks, right? (suggestion 2 and 4 work together to fix those problems WITHOUT ADDING MORE FEES).

But suggestion 3 is good for people who want to give longer buy options outside of the trading range and charge a fee for that extra value.

Please use the counterparty forum to comment/improve since this thread is so bloated but that post summarizes it well enough.

[JahPowerBit]

I just made a push.
These actions are now available:
send, order, btcpay, cancel, issuance, dividend, callback, broadcast and bet.

https://github.com/JahPowerBit/BoottleXCP

[lonsharim]

With regards to your GUI question... that is the whole point of a web wallet, there *is* no installation. No counterpartyd to set up and install. You simply go to a webpage, generate a passphrase, paste it into a text box, and click login. Takes all of 5 seconds. Nothing to save or worry about beyond your pass phrase (which *is* your wallet)

This kinda reminds me of NXT - any chance we run into same security problems with that, as they did?

Just need to have the (brain)wallet refuse or complain a LOT about low entropy passwords

Whoa back up now. You guys are going to implement the online wallet as a brain wallet???

This is incredibly insecure.

What is wrong with generating random public address / private key pairs like all other online wallets?

Isn’t blockchain.info essentially a brain wallet anyway, since all you need to generate the key is the original passphrase?

Personally I like the brain wallet idea, but why not just implement James' suggestion and refuse any passwords that are shorter than, say, 30 characters? And have a big warning about choosing a secure password. 

Could also consider adding an optional two factor login with Google authenticator or something similar.

I could be wrong, but I don't think blockchain.info or any other reputable online wallets use your passphrase to generate a private key / public address pair. My reasoning is you can generate multiple addresses in your blockchain.info wallet. If it were a true brain wallet your passphrase would map 1-to-1 to one address and you wouldn't be able to have more than one address.

It's possible they use your password as additional entropy when generating their addresses, but I think that's unlikely as well.

With a standard username/password combo you can feel safe knowing that even if you chose a crappy password the attacker still has to attack the site itself which lowers password cracking bandwidth by several orders of magnitude. If you choose a crappy brainwallet password the attacker can use his GPU/FPGA/ASIC farm to pwn you at mega-speed.

I don't know how blockchain implements their online wallet but a basic minimum requirement is the identifier which combined with the password give you access. Sure you don't need to know your identifier if you set up an alias but having an identifier increases security as compared to solo passwords access into your wallet.

Secondly if an identifier is implemented then it can be disabled if someone is making multiple guesses.

Bots have been written to continuously guess passwords on the nxt wallet, if someone has been foolish enough to set a weak password and the bot gains access the balances are transferred out. I remember someone created a wallet with 10 nxt coins as an experiment with a basic password, the balance was transferred with the hour.

I would hate to see us repeat the same mistakes as nxt. Hopefully not.

[lonsharim]

I just made a push.
These actions are now available:
send, order, btcpay, cancel, issuance, dividend, callback, broadcast and bet.

https://github.com/JahPowerBit/BoottleXCP

A couple of questions on https://code.google.com/p/chromiumembedded/

Download links to both CEF1 and CEF3 are available. Should I be downloading CEF3?
I am running Windows 8 64 bit, CEF3 windows 64 shows up as experimental. It is OK to use the 64 bit or do you recommend the 32 bit install.

[Anotheranonlol]

I just made a push.
These actions are now available:
send, order, btcpay, cancel, issuance, dividend, callback, broadcast and bet.

https://github.com/JahPowerBit/BoottleXCP

Where does the name Boottle come from?

XCP GUI with bottlepy and Bootstrap

[Anotheranonlol]

With regards to your GUI question... that is the whole point of a web wallet, there *is* no installation. No counterpartyd to set up and install. You simply go to a webpage, generate a passphrase, paste it into a text box, and click login. Takes all of 5 seconds. Nothing to save or worry about beyond your pass phrase (which *is* your wallet)

This kinda reminds me of NXT - any chance we run into same security problems with that, as they did?

Just need to have the (brain)wallet refuse or complain a LOT about low entropy passwords

Whoa back up now. You guys are going to implement the online wallet as a brain wallet???

This is incredibly insecure.

What is wrong with generating random public address / private key pairs like all other online wallets?

what's all the talk about brain wallet insecurity? as I understood on description the site would generate 12 word seed itself,something like blockchain, electrum or http://carbonwallet.com/ https://github.com/carbonwallet/carbonwallet.github.io

[delulo]

Ok.So running xcp on top of an altcoin is possible. But is it possible to run xcp on an own blockchain and if so is that an option / planned?  

And would the GUI client allow an easy installation?

Not sure what you mean exactly by "counterparty with proof of stake on an own chain (or nxt or ppc)" ... https://counterparty.co/faqs/can-counterparty-work-on-blockchains-other-than-bitcoin/

Counterparty could probably work on a hybrid POS blockchain like PPC.... the key is really around being able to encode the data into both the POW blocks and the POS blocks. I'm not 100% certain of the state of PPC's multisig support (and it probably doesn't relay OP_RETURN currently, as that's just coming around for bitcoin itself). However, as long as we can do multisig into the blocks, then in concept counterparty could be made to work with a different Bitcoin-based blockchain. Note that there are other technical considerations that would need to be taken into account as well that could have an impact on the implementation, such as block timing.

With things like NXT, that's totally up in the air, as it's not based around Bitcoin. I don't know enough about it to say one way or the other. Probably just simpler for NXT to develop that kind of functionality natively.

With regards to your GUI question... that is the whole point of a web wallet, there *is* no installation. No counterpartyd to set up and install. You simply go to a webpage, generate a passphrase, paste it into a text box, and click login. Takes all of 5 seconds. Nothing to save or worry about beyond your pass phrase (which *is* your wallet)

Do you see a long term issue with being based on proof of work and not having an own dedicated blockchain in terms of transaction times, scalability/economic efficiency (through mining costs) and security (malevolent 51% attacks)?

[doitnow]

Hi guys. When I tried to run counterpartyd this evening this pop up: C:\Python32\python.exe is not valid Win32 application
Any idea?

[IamNotSure]

Hi guys. When I tried to run counterpartyd this evening this pop up: C:\Python32\python.exe is not valid Win32 application
Any idea?

I had that error once. Looks like a Dll of some sort was corrupted.

Best bet is to desinstall python and all the libs then reinstall everything. It worked for me !

[xibeijan]

Uh Oh, looks like one of the alpha-testers broke the market system for exchanging XCP/BTC:
http://www.blockscan.com/order_book.aspx

SETTING THE MINIMUM PRICE TO 0.09999910 BTC/XCP  !!!!

... it looks more like a planned execution to block any exchanges from taking place  .. The DEX was actually working quite well for the low volume trades.

I think this really does go back to the point that there should be some "abuse" checks in place, without these then if left to market forces the DEX would be non functional....

I was thinking that as alternative to the DEX matching the highest price, why not put in an option to match trades based on a specific tx_hash

for example a command like counterpartd.py order --offer_hash=6ecb7518eaabf0a655ea6f67af9145cb625f08e43cdb8884ba4959a9c404e99e could be executed. This could work for orders selling BTC for XCP

The orders would then parse by blocks.py and match the specific --offer_hash. If for some reason the order has already been filled or does not meet the criteria then full AUTO cancel and refund takes places.

Really, I think the correct solution is that XCP shouldn't let someone place an order that exceeds their respective balance(s).

[doitnow]

Hi guys. When I tried to run counterpartyd this evening this pop up: C:\Python32\python.exe is not valid Win32 application
Any idea?

I had that error once. Looks like a Dll of some sort was corrupted.

Best bet is to desinstall python and all the libs then reinstall everything. It worked for me !

I was afraid of it but it seems that is only way to get that done. Thanks IamNotSure

[xibeijan]

I didn't see an answer, so I'll ask again....

What happens to the 5 XCM fee you pay when you issue an asset?

I believe they are burnt

So this serves as a form of deflation for XCP?

One other related question, why is the fee for sending XCP so expensive?  That is, the bitcoin min tx fee is 0.0001, while to send XCP costs me 0.0003XXX 

Anyone able to give definitive to questions above?  First question is most important.

Yes.

Those aren't fees---the funds are returned to you.

Thanks.

I didn't get refunded the full 5XCP.  it cost me 0.1 XCP to issue an asset.   bug?

[xibeijan]

Very interesting.  Can you point me in the direction of how to recover my multisig fees?

[xibeijan]

Uh Oh, looks like one of the alpha-testers broke the market system for exchanging XCP/BTC:
http://www.blockscan.com/order_book.aspx

SETTING THE MINIMUM PRICE TO 0.09999910 BTC/XCP  !!!!

... it looks more like a planned execution to block any exchanges from taking place  .. The DEX was actually working quite well for the low volume trades.

I think this really does go back to the point that there should be some "abuse" checks in place, without these then if left to market forces the DEX would be non functional....

I was thinking that as alternative to the DEX matching the highest price, why not put in an option to match trades based on a specific tx_hash

for example a command like counterpartd.py order --offer_hash=6ecb7518eaabf0a655ea6f67af9145cb625f08e43cdb8884ba4959a9c404e99e could be executed. This could work for orders selling BTC for XCP

The orders would then parse by blocks.py and match the specific --offer_hash. If for some reason the order has already been filled or does not meet the criteria then full AUTO cancel and refund takes places.

Really, I think the correct solution is that XCP shouldn't let someone place an order that exceeds their respective balance(s).

BTW: doesn't this mean that XCP cannot sell below 0.09 BTC until that 55480.18704735 BTC order either expires or is matched?

[PhantomPhreak]

BTW: doesn't this mean that XCP cannot sell below 0.09 BTC until that 55480.18704735 BTC order either expires or is matched?

No, it doesn't. If there are two bids at .005 and .006, then a new ask at .004 will match the bid at .005 first. (This is a weird and perhaps surprising, and I'm not sure that it shouldn't be changed. Prices should converge either way, however.)

Of course, even if that weren't the case, one could also trade with a higher fee_required (which is what everyone should have been doing all along).

[cityglut]

BTW: doesn't this mean that XCP cannot sell below 0.09 BTC until that 55480.18704735 BTC order either expires or is matched?

No, it doesn't. If there are two bids at .005 and .006, then a new ask at .004 will match the bid at .005 first. (This is a weird and perhaps surprising, and I'm not sure that it shouldn't be changed. Prices should converge either way, however.)

Of course, even if that weren't the case, one could also trade with a higher fee_required (which is what everyone should have been doing all along).

But nobody wants to pay 0.01 BTC = $7 just to make a trade...nobody will use the Dex if that's the solution.

So what troll-negation tactics have we decided to go with, if any? In no particular order:

1) optional XCP escrow
2) fixed 10 block expiry for BTCpay (I think I saw this in a github commit?)
3) optional XCP fee paid to seller on order-match
4) a failed BTCpay leads to cancelling all buyer orders and outstanding order-matches
 

fee_required is now a percentage of the total BTC worth of an asset that one is buying, and an address's fee_provided is deducted cumulatively. So, if there are five XCP-for-BTC orders for 1 BTC each, the fee_provided for a BTC-for-XCP order must be .05 BTC, not .01 in order to match all of them.

We are also still considering implementing the optional XPC escrow.

EDIT: the fee_required/fee_provided default to 1% and fee_required/fee_provided no longer needs to be an argument of an order. Users can however change the fee just be including fee_required/fee_provided as an argument of an order

EDIT 2: And there is a fixed 10 block expiry for btcpay as you noted.