Quote
0.01 BTC for 1.0 XCP
OK, so we're now expected to pay 10-15x of what people burned BTC for 2 days ago.... sure.
If somebody wants to do a decent, non-scammy trade, I'll offer 0.0015 btc/xpc.
Topic: [ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread - page 558. (Read 1276933 times)
February 03, 2014, 05:48:27 PM
OK, so we're now expected to pay 10-15x of what people burned BTC for 2 days ago.... sure.
If somebody wants to do a decent, non-scammy trade, I'll offer 0.0015 btc/xpc.
February 03, 2014, 05:07:46 PM
Everyone, please help spread the word. To be successful as an asset trading and betting platform for financial instruments, we need broad community participation not just few early adopters.
Is there any reason the burn was not really publicized much? I first learned of XCP when I saw the post-burn thread on reddit late last night, already in bed, and immediately felt burned myself (haha!) for not having found out in time. I think I need to cool off a little before buying in, especially since the price is now around 10x and we don't seem to be out of the a-future-update-might-not-be-backward-compatible-and-you-might-lose-it-all development phase.
Anyway, I'm a professional copywriter and I would still like to offer my services to proof/correct/improve any communications you want to send out, even if I'm not yet invested in XCP. I think Patel was preparing a PR.
I'm not sure how it could have been advertised more? This thread has 108 pages and 38,400 page views. Short of taking out a paid advertisement somewhere, what can you do?
FWIW I actually read about it in the Ethereum thread and though it might have potential, so came over here and started reading up on it.
February 03, 2014, 03:58:45 PM
So what was the result of the Super Bowl bet between me and jimhsu?
I can see on blockscan that I've been credited 1 XCP from winning the bet since I only received 1340 XCP from burning and my "total received" shows 1341 XCP:
http://blockscan.com/address.aspx?q=1QBPsB2ea61vWTNA9nGUhaHqPQB4SXF4fN
However, my balance is still 1340. What is causing this discrepancy?
I can see on blockscan that I've been credited 1 XCP from winning the bet since I only received 1340 XCP from burning and my "total received" shows 1341 XCP:
http://blockscan.com/address.aspx?q=1QBPsB2ea61vWTNA9nGUhaHqPQB4SXF4fN
However, my balance is still 1340. What is causing this discrepancy?
What should your balance be? I found a bug in the bet expiration code, and now I'm getting 1399.41 XCP.
EDIT: In addition to that problem, the bet isn't being settled, it seems.
The reason that the bet wasn't settled is that the broadcast you made announcing the result was timestamped before the bet's deadline, which was a few hours ago. You just need to make another broadcast with the same values now (counterpartyd does the timestamping automatically).
EDIT: The expiration bug should have only affected the develop branch.
February 03, 2014, 03:54:29 PM
Everyone, please help spread the word. To be successful as an asset trading and betting platform for financial instruments, we need broad community participation not just few early adopters.
Is there any reason the burn was not really publicized much? I first learned of XCP when I saw the post-burn thread on reddit late last night, already in bed, and immediately felt burned myself (haha!) for not having found out in time. I think I need to cool off a little before buying in, especially since the price is now around 10x and we don't seem to be out of the a-future-update-might-not-be-backward-compatible-and-you-might-lose-it-all development phase.
Anyway, I'm a professional copywriter and I would still like to offer my services to proof/correct/improve any communications you want to send out, even if I'm not yet invested in XCP. I think Patel was preparing a PR.
February 03, 2014, 03:47:32 PM
So what was the result of the Super Bowl bet between me and jimhsu?
I can see on blockscan that I've been credited 1 XCP from winning the bet since I only received 1340 XCP from burning and my "total received" shows 1341 XCP:
http://blockscan.com/address.aspx?q=1QBPsB2ea61vWTNA9nGUhaHqPQB4SXF4fN
However, my balance is still 1340. What is causing this discrepancy?
I can see on blockscan that I've been credited 1 XCP from winning the bet since I only received 1340 XCP from burning and my "total received" shows 1341 XCP:
http://blockscan.com/address.aspx?q=1QBPsB2ea61vWTNA9nGUhaHqPQB4SXF4fN
However, my balance is still 1340. What is causing this discrepancy?
What should your balance be? I found a bug in the bet expiration code, and now I'm getting 1399.41 XCP.
EDIT: In addition to that problem, the bet isn't being settled, it seems.
February 03, 2014, 03:45:53 PM
I ran reparse, but it says its not a valid choice.
purgue will reparse the counterparty DB.
Thank you!
Thanks Phantom for the fix, the XCP is now showing in the wallet.
Man that is great to hear Patel!
February 03, 2014, 03:21:12 PM
You don't want to do a BTCpay right before the order match is set to expire (especially in the future, when blocks are closer to being full).
Can this be foolproofed somehow before going mainstream? I'd hate to think of all the posts on the forums when people start losing BTC. Maybe the BTCpay operation can accept an order match number as an optional parameter and the escrow time extended if necessary for the amount of that specific order only, provided BTCpay is called before the offer expires. The number of blocks to extend would be based on what the protocol determines is reasonable at the time or could be hardcoded initially.
This will come with the GUI/online client. Btcpay right now is not at all user friendly, (neither is order matching), but remember this is alpha quality software. Bitcoin wasn't built in a day (or for that matter, a year).
I encourage people to sign up for reddit (if you haven't already) and try to answer outstanding questions in the reddit thread: http://www.reddit.com/r/Bitcoin/comments/1wtz2b/2124_btc_destroyed_in_proofofburn/
A lot of people are sold on the idea (unlike, for instance, NXT); they just want to know how to acquire some XCP.
Everyone, please help spread the word. To be successful as an asset trading and betting platform for financial instruments, we need broad community participation not just few early adopters.
February 03, 2014, 03:14:19 PM
Done it.
unfortunately this error came up:
unfortunately this error came up:
Code:
C:\counterpartyd_build>C:\counterpartyd_build\run.py burn --from=1CibkcwpBRZAMZU
wv6hXE1eNoZ8Mb38cQg --quantity=0.0029
Confirm? (y/N) y
Traceback (most recent call last):
File "C:\counterpartyd_build\dist\counterpartyd\counterpartyd.py", line 585, i
n
json_print(bitcoin.transmit(unsigned_tx_hex, unsigned=args.unsigned))
File "C:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 315, in
transmit
return rpc('sendrawtransaction', [signed_tx_hex])
File "C:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 69, in r
pc
raise exceptions.BitcoindError('{}'.format(response_json['error']))
lib.exceptions.BitcoindError: {'message': 'TX rejected', 'code': -22}
C:\counterpartyd_build>
wv6hXE1eNoZ8Mb38cQg --quantity=0.0029
Confirm? (y/N) y
Traceback (most recent call last):
File "C:\counterpartyd_build\dist\counterpartyd\counterpartyd.py", line 585, i
n
json_print(bitcoin.transmit(unsigned_tx_hex, unsigned=args.unsigned))
File "C:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 315, in
transmit
return rpc('sendrawtransaction', [signed_tx_hex])
File "C:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 69, in r
pc
raise exceptions.BitcoindError('{}'.format(response_json['error']))
lib.exceptions.BitcoindError: {'message': 'TX rejected', 'code': -22}
C:\counterpartyd_build>
Code:
'TX rejected', 'code': -22
TX rejected?I am getting this same error when sending.
If anyone gets this error, it gets caused because when you send, it will send the change outputs to a different address. And you need to put them back onto your XCP address.
An easy fix for this is to send multiple outputs of 0.0003172 to your XCP address, so every time you send, or do a order, it will use one of the multiple outputs instead of sending the change to a different address.
========
Selling 1k XCP for 7.5btc
counterpartyd always sends the change back to the source address. The problem might be that those change inputs remain unconfirmed for a while, however.
February 03, 2014, 03:05:27 PM
Done it.
unfortunately this error came up:
unfortunately this error came up:
Code:
C:\counterpartyd_build>C:\counterpartyd_build\run.py burn --from=1CibkcwpBRZAMZU
wv6hXE1eNoZ8Mb38cQg --quantity=0.0029
Confirm? (y/N) y
Traceback (most recent call last):
File "C:\counterpartyd_build\dist\counterpartyd\counterpartyd.py", line 585, i
n
json_print(bitcoin.transmit(unsigned_tx_hex, unsigned=args.unsigned))
File "C:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 315, in
transmit
return rpc('sendrawtransaction', [signed_tx_hex])
File "C:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 69, in r
pc
raise exceptions.BitcoindError('{}'.format(response_json['error']))
lib.exceptions.BitcoindError: {'message': 'TX rejected', 'code': -22}
C:\counterpartyd_build>
wv6hXE1eNoZ8Mb38cQg --quantity=0.0029
Confirm? (y/N) y
Traceback (most recent call last):
File "C:\counterpartyd_build\dist\counterpartyd\counterpartyd.py", line 585, i
n
json_print(bitcoin.transmit(unsigned_tx_hex, unsigned=args.unsigned))
File "C:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 315, in
transmit
return rpc('sendrawtransaction', [signed_tx_hex])
File "C:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 69, in r
pc
raise exceptions.BitcoindError('{}'.format(response_json['error']))
lib.exceptions.BitcoindError: {'message': 'TX rejected', 'code': -22}
C:\counterpartyd_build>
Code:
'TX rejected', 'code': -22
TX rejected?I am getting this same error when sending.
If anyone gets this error, it gets caused because when you send, it will send the change outputs to a different address. And you need to put them back onto your XCP address.
An easy fix for this is to send multiple outputs of 0.0003172 to your XCP address, so every time you send, or do a order, it will use one of the multiple outputs instead of sending the change to a different address.
========
Selling 1k XCP for 7.5btc
February 03, 2014, 03:04:34 PM
Forgive my questions: I'm very newb (not overly technical).
Let's say I want to list 10 XCP for 0.01 BTC each. I want my offer to expire in approx 24 hours, and I want to give the buyer approx 1 hour to transfer the BTC. What would I put on the command line in counterpartyd to do this?
Let's say I want to list 10 XCP for 0.01 BTC each. I want my offer to expire in approx 24 hours, and I want to give the buyer approx 1 hour to transfer the BTC. What would I put on the command line in counterpartyd to do this?
February 03, 2014, 02:55:46 PM
A lot of people are sold on the idea; they just want to know how to acquire some XCP.
Exactly.Jimhsu you are welcome to comment on my proposal to make that simpler.
(or explain me what I miss and/or don't grasp in multisig creation / data attachment)
February 03, 2014, 02:53:54 PM
You don't want to do a BTCpay right before the order match is set to expire (especially in the future, when blocks are closer to being full).
Can this be foolproofed somehow before going mainstream? I'd hate to think of all the posts on the forums when people start losing BTC. Maybe the BTCpay operation can accept an order match number as an optional parameter and the escrow time extended if necessary for the amount of that specific order only, provided BTCpay is called before the offer expires. The number of blocks to extend would be based on what the protocol determines is reasonable at the time or could be hardcoded initially.
I think maybe there is some confusion here?
There are two different Expiration Scenarios. 1) The expiration of the unfilled order (order-expiration). 2) The expiration of the time period a buyer has to send bitcoins to the seller through BTCPay (order-match-expiration).
From what I understand PhantomPhreak is talking about order-match-expiration. For example, an order is matched and the buyer has to push a BTCPay transaction to the blockchain within 5 blocks. He pushes it before 5 blocks are finished but it takes longer than that for his transaction to be confirmed. He loses his bitcoins in this scenario.
In terms of order-expiration, that should never cause you to lose bitcoins. When the order is matched, the order is no longer unfilled and therefore the order-expiration is no longer relevant.
Please correct me if I'm wrong.
You are correct, I believe.
February 03, 2014, 02:45:12 PM
You don't want to do a BTCpay right before the order match is set to expire (especially in the future, when blocks are closer to being full).
Can this be foolproofed somehow before going mainstream? I'd hate to think of all the posts on the forums when people start losing BTC. Maybe the BTCpay operation can accept an order match number as an optional parameter and the escrow time extended if necessary for the amount of that specific order only, provided BTCpay is called before the offer expires. The number of blocks to extend would be based on what the protocol determines is reasonable at the time or could be hardcoded initially.
This will come with the GUI/online client. Btcpay right now is not at all user friendly, (neither is order matching), but remember this is alpha quality software. Bitcoin wasn't built in a day (or for that matter, a year).
I encourage people to sign up for reddit (if you haven't already) and try to answer outstanding questions in the reddit thread: http://www.reddit.com/r/Bitcoin/comments/1wtz2b/2124_btc_destroyed_in_proofofburn/
A lot of people are sold on the idea (unlike, for instance, NXT); they just want to know how to acquire some XCP.
February 03, 2014, 02:39:41 PM
You don't want to do a BTCpay right before the order match is set to expire (especially in the future, when blocks are closer to being full).
Can this be foolproofed somehow before going mainstream? I'd hate to think of all the posts on the forums when people start losing BTC. Maybe the BTCpay operation can accept an order match number as an optional parameter and the escrow time extended if necessary for the amount of that specific order only, provided BTCpay is called before the offer expires. The number of blocks to extend would be based on what the protocol determines is reasonable at the time or could be hardcoded initially.
February 03, 2014, 02:37:32 PM
Any clarification on BTCPAY?
Here are some useful commands
cd C:\counterpartyd_build
C:\Python32\python.exe run.py server
C:\Python32\python.exe run.py send --from=1xx --quantity=xx --asset=XCP --to=1xx
C:\Python32\python.exe run.py order --from=1xx --get-quantity=xx --get-asset=XCP --give-quantity=xx --give-asset=BTC --expiration=3 --fee_required=.001
C:\Python32\python.exe run.py btcpay --order-match-id=[enter tx hashes of both orders, combined]
C:\Python32\python.exe run.py cancel --offer-hash=[enter tx hash here]
February 03, 2014, 02:36:12 PM
I see a few have trouble to grasp the order & btcpay process.
These 2 example might help:
Alice give 50 XCP for 1 BTC, blocktime 100 [XCP put in escrow, timer 1]
Bob give 1 BTC for 50 XCP, blocktime 10 [no BTC put in escrow, timer 2]
Need 1 blocktime to match
Bob will have 9 blocktime to btcpay with the matching Order ID [timer 3 = new timer]
Alice give 50 XCP for 1 BTC, blocktime 20 [XCP put in escrow only a short time]
Bob give 1 BTC for 50 XCP, blocktime 200 [not BTC put in escrow]
Need 1 blocktime to match
Bob will have 19 blocktime to btcpay the matching Order ID
I haven't test, but I guess if there is only 1blocktime left for a matching order:
either it pass at the last moment and the exchange is done
or there is a message error that the Order ID has expired.
I hope it helped.
Tired, sorry if I answered aside to something that wasn't asked.
These 2 example might help:
Alice give 50 XCP for 1 BTC, blocktime 100 [XCP put in escrow, timer 1]
Bob give 1 BTC for 50 XCP, blocktime 10 [no BTC put in escrow, timer 2]
Need 1 blocktime to match
Bob will have 9 blocktime to btcpay with the matching Order ID [timer 3 = new timer]
Alice give 50 XCP for 1 BTC, blocktime 20 [XCP put in escrow only a short time]
Bob give 1 BTC for 50 XCP, blocktime 200 [not BTC put in escrow]
Need 1 blocktime to match
Bob will have 19 blocktime to btcpay the matching Order ID
I haven't test, but I guess if there is only 1blocktime left for a matching order:
either it pass at the last moment and the exchange is done
or there is a message error that the Order ID has expired.
I hope it helped.
Tired, sorry if I answered aside to something that wasn't asked.
February 03, 2014, 02:26:39 PM
I ran reparse, but it says its not a valid choice.
purgue will reparse the counterparty DB.
Thank you!
Thanks Phantom for the fix, the XCP is now showing in the wallet.
February 03, 2014, 02:24:20 PM
your btc don't leave when you place an order, after an order is matched, then you send the btc. I am not sure if orders will stay matched after expiration though.
I think we have the same question...
What happens if the XCP sale offer expires before the BTC arrive? Are you now at the mercy of the seller to return your BTC or choose to honor the trade? If I have understood correctly, Counterparty can only escrow XCP and assets generated inside its system.
I think yes, you are at the mercy of the seller..
That would make the examples I saw of trades (not real ones) with expirations of 3 to 5 blocks very tight, no? Especially when you account for the randomness of block generation.
You don't want to do a BTCpay right before the order match is set to expire (especially in the future, when blocks are closer to being full).
February 03, 2014, 02:19:01 PM
I ran reparse, but it says its not a valid choice.
purgue will reparse the counterparty DB.
February 03, 2014, 02:12:08 PM
your btc don't leave when you place an order, after an order is matched, then you send the btc. I am not sure if orders will stay matched after expiration though.
I think we have the same question...
What happens if the XCP sale offer expires before the BTC arrive? Are you now at the mercy of the seller to return your BTC or choose to honor the trade? If I have understood correctly, Counterparty can only escrow XCP and assets generated inside its system.
I think yes, you are at the mercy of the seller..
That would make the examples I saw of trades (not real ones) with expirations of 3 to 5 blocks very tight, no? Especially when you account for the randomness of block generation.
Jump to: