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

[relm9]

Might be a stupid question, but can I burn twice from the same address? i.e. just send 0.01 BTC as a test, then send the rest

Yes, as long as it doesn't exceed 1BTC, but you can send 0.01BTC as a test and 0.99BTC afterwards.

Great, thanks.

[BitThink]

Might be a stupid question, but can I burn twice from the same address? i.e. just send 0.01 BTC as a test, then send the rest

Yes, but make sure that address still has enough BTC. Otherwise, if the client combine the inputs from multiple addresses, you will lose what you have burnt. Of course, you will be safe if you are burning with the counterpartyd.

[romerun]

180+ coins burnt today, if this project and MSC fail, 1CounterXX, and 1Exodus would be in the alltime memes of btc history.

[BitThink]

180+ coins burnt today, if this project and MSC fail, 1CounterXX, and 1Exodus would be in the alltime memes of btc history.

1CounterXX is, but not 1Exodus since its just a normal address and all the funds inside will be spent at last. The funds in 1CouterXXX..., however, will be there forever, no matter counterparty succeeds or fails.

[led_lcd]

Error in a transaction in block 280807. Just before I was going to do a burn. Typical 

Code:

Block: 280807
Traceback (most recent call last):
  File "/home/jeremy/counterpartyd_build/dist/counterpartyd/counterpartyd.py", line 618, in <module>
    blocks.follow(db)
  File "/home/jeremy/counterpartyd_build/dist/counterpartyd/lib/blocks.py", line 516, in follow
    raise e
  File "/home/jeremy/counterpartyd_build/dist/counterpartyd/lib/blocks.py", line 509, in follow
    parse_block(db, block_index)
  File "/home/jeremy/counterpartyd_build/dist/counterpartyd/lib/blocks.py", line 57, in parse_block
    issuance.parse(db, tx, message)
  File "/home/jeremy/counterpartyd_build/dist/counterpartyd/lib/issuance.py", line 108, in parse
    validity)
OverflowError: Python int too large to convert to SQLite INTEGER

[Asterios]

Error in a transaction in block 280807. Just before I was going to do a burn. Typical 

Code:

Block: 280807
Traceback (most recent call last):
  File "/home/jeremy/counterpartyd_build/dist/counterpartyd/counterpartyd.py", line 618, in <module>
    blocks.follow(db)
  File "/home/jeremy/counterpartyd_build/dist/counterpartyd/lib/blocks.py", line 516, in follow
    raise e
  File "/home/jeremy/counterpartyd_build/dist/counterpartyd/lib/blocks.py", line 509, in follow
    parse_block(db, block_index)
  File "/home/jeremy/counterpartyd_build/dist/counterpartyd/lib/blocks.py", line 57, in parse_block
    issuance.parse(db, tx, message)
  File "/home/jeremy/counterpartyd_build/dist/counterpartyd/lib/issuance.py", line 108, in parse
    validity)
OverflowError: Python int too large to convert to SQLite INTEGER

Same here. Except it is on block 280518 for me.

[SyRenity]

Are there any plans to implement a voting system, in order to allow the community to express their opinion on protocol or client changes?

AFAIK DAC's should allow this.

Will be nice to hear dev's opinion about this, so the community could decide together on important decisions in a truly democratic fashion.

[sumantso]

So can anybody help me? I folowed the steps and installed counterpartyd (Win 32) and while trying to run it says 'could not connect to bitcoin-qt'. I am running bitcoin in testnet as a server.

I assume its to do with counterpartyd.conf?

[maxmint]

Error in a transaction in block 280807. Just before I was going to do a burn. Typical 

Code:

Block: 280807
Traceback (most recent call last):
  File "/home/jeremy/counterpartyd_build/dist/counterpartyd/counterpartyd.py", line 618, in <module>
    blocks.follow(db)
  File "/home/jeremy/counterpartyd_build/dist/counterpartyd/lib/blocks.py", line 516, in follow
    raise e
  File "/home/jeremy/counterpartyd_build/dist/counterpartyd/lib/blocks.py", line 509, in follow
    parse_block(db, block_index)
  File "/home/jeremy/counterpartyd_build/dist/counterpartyd/lib/blocks.py", line 57, in parse_block
    issuance.parse(db, tx, message)
  File "/home/jeremy/counterpartyd_build/dist/counterpartyd/lib/issuance.py", line 108, in parse
    validity)
OverflowError: Python int too large to convert to SQLite INTEGER

It seems someone tried to create asset "NEXT" in block 280807:
https://blockchain.info/tx/acddcd5bc59349de709b0031e95c5610c233728548e8b308e32efb5d50385ee9

This asset was created with a very large quantity of 2^63 (9223372036854775808) which seems to cause this error.

[PhantomPhreak]

Error in a transaction in block 280807. Just before I was going to do a burn. Typical 

Code:

Block: 280807
Traceback (most recent call last):
  File "/home/jeremy/counterpartyd_build/dist/counterpartyd/counterpartyd.py", line 618, in <module>
    blocks.follow(db)
  File "/home/jeremy/counterpartyd_build/dist/counterpartyd/lib/blocks.py", line 516, in follow
    raise e
  File "/home/jeremy/counterpartyd_build/dist/counterpartyd/lib/blocks.py", line 509, in follow
    parse_block(db, block_index)
  File "/home/jeremy/counterpartyd_build/dist/counterpartyd/lib/blocks.py", line 57, in parse_block
    issuance.parse(db, tx, message)
  File "/home/jeremy/counterpartyd_build/dist/counterpartyd/lib/issuance.py", line 108, in parse
    validity)
OverflowError: Python int too large to convert to SQLite INTEGER

It seems someone tried to create asset "NEXT" in block 280807:
https://blockchain.info/tx/acddcd5bc59349de709b0031e95c5610c233728548e8b308e32efb5d50385ee9

This asset was created with a very large quantity of 2^63 (9223372036854775808) which seems to cause this error.

Yes, my hackish solution from two days ago was off by one, and someone exploited that. I think that I've figured out the correct fix, however, but it requires a DB rebuild, so it'll be a few minutes before I can test it properly and push the commit.

[PhantomPhreak]

Are there any plans to implement a voting system, in order to allow the community to express their opinion on protocol or client changes?

AFAIK DAC's should allow this.

Will be nice to hear dev's opinion about this, so the community could decide together on important decisions in a truly democratic fashion.

I would very much like to see that happen eventually, yes.

[halfcab123]

From what I'm seeing on Blockscan, the last 20 burns didn't go through.

[maxmint]

So for all the folks that just burnt BTC like... 10 burns lost forever ? I just burned 1 BTC and it shows on blockscan.com but no XCP given.... wtf  

Blockscan will have to rebuild it's database once the source code got updated. I guess that all burns are safe, they are recorded in the blockchain after all.

[mtbitcoin]

From what I'm seeing on Blockscan, the last 20 burns didn't go through.

They should go through once the bug issue reported earlier is fixed uploaded to git. So as long as you burnt them correctly with the instructions provided in this thread you should be good to go

Cheers

[halfcab123]

Ok lemme delete my panic posts! Thanks! haha sorry noob here.

[halfcab123]

From what I'm seeing on Blockscan, the last 20 burns didn't go through.

They should go through once the bug issue reported earlier is fixed uploaded to git. So as long as you burnt them correctly with the instructions provided in this thread your should be good to go

Cheers

Hey MTBITCOIN ? Where do you see this project headed? I burned 5 BTC. You think I'm in a good spot ? I just have 2 other questions. Can you point me in the direction of understanding how to get Bitcoin-qt working with counterpartyd.... and will that help me consolidate my XCP ? Cause I have like.. 6,500ish XCP on 5 different BTC addresses. Thanks for any input!

[mtbitcoin]

It seems someone tried to create asset "NEXT" in block 280807:
https://blockchain.info/tx/acddcd5bc59349de709b0031e95c5610c233728548e8b308e32efb5d50385ee9

This asset was created with a very large quantity of 2^63 (9223372036854775808) which seems to cause this error.

Yes, my hackish solution from two days ago was off by one, and someone exploited that. I think that I've figured out the correct fix, however, but it requires a DB rebuild, so it'll be a few minutes before I can test it properly and push the commit.
[/quote]

Would appreciate if you can post a quick update once the commit has been pushed.

cheers

[halfcab123]

So is there any practical way to use the Bitcoin Qt wallet as .. an XCP wallet ?

[PhantomPhreak]

Yes, my hackish solution from two days ago was off by one, and someone exploited that. I think that I've figured out the correct fix, however, but it requires a DB rebuild, so it'll be a few minutes before I can test it properly and push the commit.

Would appreciate if you can post a quick update once the commit has been pushed.

cheers

Sure. I'm still wrestling with SQLite3 and I have to go AFK for a couple of hours. I'll fix the problem soon!

[panonym]

So is there any practical way to use the Bitcoin Qt wallet as .. an XCP wallet ?

It's created this way. All smooth.
You burn BTC, XCP are created and linked to your pubkey in your BTC wallet.dat

--------

I'm impressed by the burn amount! 1114BTC O.o
Over 300 BTC (over 250'000$) since I last checked! went crazy fast.
Do we have a few heavy heavy burner? over 100 BTC?
I didn't check the transaction record.

I also got the OverflowError: Python int too large to convert to SQLite INTEGER (at block 280807)
I have to update, maybe it's already solved.

PhantomPhreak, may I ask own you manage to see that someone tried to create asset "NEXT" in block 280807?
Can average user also see these kind of thing?
I see nothing from blockchain.info