Bitcoin Forum
October 09, 2024, 10:25:27 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 [108] 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 ... 661 »
  Print  
Author Topic: [ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread  (Read 1276539 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
BitThink
Legendary
*
Offline Offline

Activity: 882
Merit: 1000



View Profile
February 04, 2014, 08:50:41 AM
 #2141

Can @phantomphreak please address the claims made by ethereum founder in bitcoin magazine?

http://bitcoinmagazine.com/9671/ethereum-next-generation-cryptocurrency-decentralized-application-platform/

It seems he thinks among many things that bitcoin is not suitable to be treated as an underlying base  protocol.
One of the main reasons:

Simplified Payment Verification (see the bitcoin whitepaper Section 8 ) becomes not usable. Since the miner will not verify whether a XCP transaction is valid like they do in bitcoin transactions, to check the validity of a XCP transaction, we have to track up to the very beginning (the address sent to burn address). This requires each client to download and keep the whole blockchain.

In Ethereum, they seems to find a way to solve this problem.

Detail can be found in their whitepaper: http://www.ethereum.org/ethereum.html

Personally, I don't think this is something will make Mastercoin/XCP not usable. It just increases the downloading and parsing time.
Would it be possible to have a checkpoint file that is signed by the XCP devs that clients could load instead of the entire blockchain?
For ease of use, this is almost a requirement as few normal people will wait for hours and hours for the initial sync up
It's possible, but it will not be decentralized if there's a checkpoint. People has to trust the one who publish the checkpoint. However, I think it could be very useful to provide some trustworthy services keeping some snapshots, therefore most average users can choose to trust these services and shortcut their parsing and verification. Those trustworthy services cannot cheat others for a long time as long as there're some independent clients choose to verify transactions all by themselves.
jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1134


View Profile WWW
February 04, 2014, 09:05:02 AM
 #2142

Can @phantomphreak please address the claims made by ethereum founder in bitcoin magazine?

http://bitcoinmagazine.com/9671/ethereum-next-generation-cryptocurrency-decentralized-application-platform/

It seems he thinks among many things that bitcoin is not suitable to be treated as an underlying base  protocol.
One of the main reasons:

Simplified Payment Verification (see the bitcoin whitepaper Section 8 ) becomes not usable. Since the miner will not verify whether a XCP transaction is valid like they do in bitcoin transactions, to check the validity of a XCP transaction, we have to track up to the very beginning (the address sent to burn address). This requires each client to download and keep the whole blockchain.

In Ethereum, they seems to find a way to solve this problem.

Detail can be found in their whitepaper: http://www.ethereum.org/ethereum.html

Personally, I don't think this is something will make Mastercoin/XCP not usable. It just increases the downloading and parsing time.
Would it be possible to have a checkpoint file that is signed by the XCP devs that clients could load instead of the entire blockchain?
For ease of use, this is almost a requirement as few normal people will wait for hours and hours for the initial sync up
It's possible, but it will not be decentralized if there's a checkpoint. People has to trust the one who publish the checkpoint. However, I think it could be very useful to provide some trustworthy services keeping some snapshots, therefore most average users can choose to trust these services and shortcut their parsing and verification. Those trustworthy services cannot cheat others for a long time as long as there're some independent clients choose to verify transactions all by themselves.
Could the network provide feedback on any checkpointed file to make sure it is valid? Presumably there will always be counterpartyd's that parsed the full blockchain, so before any checkpoint file is trusted locally and used, it could make sure it is valid by checking with the overall network.

Assuming it is published on counterparty.co, matches sig, odds are very good it is valid, plus it is only for initial install. So, after quick install, check with network to make sure nobody goofed when uploading the checkpoint file. If it all checks out, then BAM! we saved 17 hours of blockchain sync time without any risk

James

http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
BitThink
Legendary
*
Offline Offline

Activity: 882
Merit: 1000



View Profile
February 04, 2014, 09:23:37 AM
 #2143

Can @phantomphreak please address the claims made by ethereum founder in bitcoin magazine?

http://bitcoinmagazine.com/9671/ethereum-next-generation-cryptocurrency-decentralized-application-platform/

It seems he thinks among many things that bitcoin is not suitable to be treated as an underlying base  protocol.
One of the main reasons:

Simplified Payment Verification (see the bitcoin whitepaper Section 8 ) becomes not usable. Since the miner will not verify whether a XCP transaction is valid like they do in bitcoin transactions, to check the validity of a XCP transaction, we have to track up to the very beginning (the address sent to burn address). This requires each client to download and keep the whole blockchain.

In Ethereum, they seems to find a way to solve this problem.

Detail can be found in their whitepaper: http://www.ethereum.org/ethereum.html

Personally, I don't think this is something will make Mastercoin/XCP not usable. It just increases the downloading and parsing time.
Would it be possible to have a checkpoint file that is signed by the XCP devs that clients could load instead of the entire blockchain?
For ease of use, this is almost a requirement as few normal people will wait for hours and hours for the initial sync up
It's possible, but it will not be decentralized if there's a checkpoint. People has to trust the one who publish the checkpoint. However, I think it could be very useful to provide some trustworthy services keeping some snapshots, therefore most average users can choose to trust these services and shortcut their parsing and verification. Those trustworthy services cannot cheat others for a long time as long as there're some independent clients choose to verify transactions all by themselves.
Could the network provide feedback on any checkpointed file to make sure it is valid? Presumably there will always be counterpartyd's that parsed the full blockchain, so before any checkpoint file is trusted locally and used, it could make sure it is valid by checking with the overall network.

Assuming it is published on counterparty.co, matches sig, odds are very good it is valid, plus it is only for initial install. So, after quick install, check with network to make sure nobody goofed when uploading the checkpoint file. If it all checks out, then BAM! we saved 17 hours of blockchain sync time without any risk

James

The problem is that even if we use a checkpoint, the size of a checkpoint file for counterparty will be much larger than a checkpoint of BTC. A checkpoint of BTC is just the hash of current block, but a checkpoint of counterparty has to snapshot the balance of each address and the status of each order, bid, broadcast etc.
Olano
Newbie
*
Offline Offline

Activity: 115
Merit: 0


View Profile
February 04, 2014, 09:26:44 AM
 #2144

Can @phantomphreak please address the claims made by ethereum founder in bitcoin magazine?

http://bitcoinmagazine.com/9671/ethereum-next-generation-cryptocurrency-decentralized-application-platform/

It seems he thinks among many things that bitcoin is not suitable to be treated as an underlying base  protocol.
One of the main reasons:

Simplified Payment Verification (see the bitcoin whitepaper Section 8 ) becomes not usable. Since the miner will not verify whether a XCP transaction is valid like they do in bitcoin transactions, to check the validity of a XCP transaction, we have to track up to the very beginning (the address sent to burn address). This requires each client to download and keep the whole blockchain.

In Ethereum, they seems to find a way to solve this problem.

Detail can be found in their whitepaper: http://www.ethereum.org/ethereum.html

Personally, I don't think this is something will make Mastercoin/XCP not usable. It just increases the downloading and parsing time.


Damn... and people burned over 2000+ BTC on a protocol that has this big gaping hole?
BitThink
Legendary
*
Offline Offline

Activity: 882
Merit: 1000



View Profile
February 04, 2014, 09:46:28 AM
 #2145

Can @phantomphreak please address the claims made by ethereum founder in bitcoin magazine?

http://bitcoinmagazine.com/9671/ethereum-next-generation-cryptocurrency-decentralized-application-platform/

It seems he thinks among many things that bitcoin is not suitable to be treated as an underlying base  protocol.
One of the main reasons:

Simplified Payment Verification (see the bitcoin whitepaper Section 8 ) becomes not usable. Since the miner will not verify whether a XCP transaction is valid like they do in bitcoin transactions, to check the validity of a XCP transaction, we have to track up to the very beginning (the address sent to burn address). This requires each client to download and keep the whole blockchain.

In Ethereum, they seems to find a way to solve this problem.

Detail can be found in their whitepaper: http://www.ethereum.org/ethereum.html

Personally, I don't think this is something will make Mastercoin/XCP not usable. It just increases the downloading and parsing time.


Damn... and people burned over 2000+ BTC on a protocol that has this big gaping hole?
No, it's just a weakness, not a show stopper.

Worse case is that you have to download the whole BTC blockchain to use Counterparty. Otherwise, you could trust some big websites to verify the transactions for you (like the blockchain.info for BTC).

The only difference with current status of BTC is that 1) it's more difficult to build a light-weight client such as Multibit, and 2) the parsing time could be long when the history of XCP becomes long.
TKeenan
Hero Member
*****
Offline Offline

Activity: 874
Merit: 1000



View Profile
February 04, 2014, 09:50:58 AM
 #2146

Damn... and people burned over 2000+ BTC on a protocol that has this big gaping hole?

The idea to throw $2 million into the toilet proves that XCP was stupid from the very beginning.  Ship of fools.  Happy sailing!
BitThink
Legendary
*
Offline Offline

Activity: 882
Merit: 1000



View Profile
February 04, 2014, 09:57:18 AM
 #2147

Try harder.

As I said. Only the progress determines the price. Your opinion, or my opinion, does not matter at all. At least for now, the progress of XCP is much faster than MSC. Let's see which ship arrives the destination first.
Alias
Full Member
***
Offline Offline

Activity: 127
Merit: 100

Money be green


View Profile
February 04, 2014, 10:20:36 AM
 #2148

Can @phantomphreak please address the claims made by ethereum founder in bitcoin magazine?

http://bitcoinmagazine.com/9671/ethereum-next-generation-cryptocurrency-decentralized-application-platform/

It seems he thinks among many things that bitcoin is not suitable to be treated as an underlying base  protocol.
One of the main reasons:

Simplified Payment Verification (see the bitcoin whitepaper Section 8 ) becomes not usable. Since the miner will not verify whether a XCP transaction is valid like they do in bitcoin transactions, to check the validity of a XCP transaction, we have to track up to the very beginning (the address sent to burn address). This requires each client to download and keep the whole blockchain.

In Ethereum, they seems to find a way to solve this problem.

Detail can be found in their whitepaper: http://www.ethereum.org/ethereum.html

Personally, I don't think this is something will make Mastercoin/XCP not usable. It just increases the downloading and parsing time.
Would it be possible to have a checkpoint file that is signed by the XCP devs that clients could load instead of the entire blockchain?
For ease of use, this is almost a requirement as few normal people will wait for hours and hours for the initial sync up
It's possible, but it will not be decentralized if there's a checkpoint. People has to trust the one who publish the checkpoint. However, I think it could be very useful to provide some trustworthy services keeping some snapshots, therefore most average users can choose to trust these services and shortcut their parsing and verification. Those trustworthy services cannot cheat others for a long time as long as there're some independent clients choose to verify transactions all by themselves.
Could the network provide feedback on any checkpointed file to make sure it is valid? Presumably there will always be counterpartyd's that parsed the full blockchain, so before any checkpoint file is trusted locally and used, it could make sure it is valid by checking with the overall network.

Assuming it is published on counterparty.co, matches sig, odds are very good it is valid, plus it is only for initial install. So, after quick install, check with network to make sure nobody goofed when uploading the checkpoint file. If it all checks out, then BAM! we saved 17 hours of blockchain sync time without any risk

James

The problem is that even if we use a checkpoint, the size of a checkpoint file for counterparty will be much larger than a checkpoint of BTC. A checkpoint of BTC is just the hash of current block, but a checkpoint of counterparty has to snapshot the balance of each address and the status of each order, bid, broadcast etc.

There is a very elegant solution (theoretically) to this problem. Decentralise the checkpointing. A DAC (Decentralised Autonomous Community/Corporation/Company, for those who aren't familiar with the concept) could ensure that a checkpoint that has been arrived at by consensus is published/broadcast.

For those of you whose eyes glaze over when they see the acronym "DAC", picture this please:

I install my "Counterparty-qt". During installation it asks me "Do you want to run a full node?". I say yes because I personally don't care about "downloading and parsing time". This installs a DAC add-on with my Counterparty-qt.

I run Counterparty-qt. In the background a checkpoint of the system is periodically being updated (presumably by block).

My CP-DAC (CounterParty-DAC) is talking to every other CP-DAC on the network. They reach a consensus of the checkpoint of the system. The DACs then publish both the checkpoint (as a torrent perhaps?) and the checksum for it (for further verification).

Those individuals choosing to run Counterparty-qt without supporting the decentralised check-pointing add-on can just download that checkpoint torrent as their starting point. This would allow them to get up and running almost immediately.

The beautiful thing here is that after the checkpoints for every block so far (and checksums corresponding to them) are published, more people could run the DAC from those points onwards at less expense (bandwidth and processing power) and contribute to the decentralised checkpointing.

Feel free to ask me any questions about this.

So, does the Counterparty Project want to have the first useful DAC as well as the first useful decentralised exchange?

TLDR: A light-weight Counterparty Protocol client is possible by utilising a DAC.

In times of change, it is the learners who will inherit the earth, while the learned will find themselves beautifully equipped for a world that no longer exists.
BitThink
Legendary
*
Offline Offline

Activity: 882
Merit: 1000



View Profile
February 04, 2014, 12:18:58 PM
 #2149

Very interesting. Could be very useful for average users.
Just one question now, how about there's a reorganization after a checkpoint is setup? There has to be a scheme to invalidate the checkpoint in a short time. Maybe associate the checkpoint with the block hash.
sumantso
Legendary
*
Offline Offline

Activity: 1050
Merit: 1000



View Profile
February 04, 2014, 12:33:10 PM
 #2150

Congrats everyone for the successful burn period. I expected it would hit 3k BTC, but less is better (for us). Can't wait for the GUI wallet to be out.

I enjoyed taking all the trouble to get counterpartyd set up and do all the stuff. I am a non-technical guy and usually its just click qt for me.

Sorry but we have MasterCoin already.  Huh

https://bitcointalk.org/index.php?topic=265488.0

Somebody was already getting the jitters - reason for his sell off?

trilli0n
Newbie
*
Offline Offline

Activity: 48
Merit: 0


View Profile
February 04, 2014, 12:39:34 PM
 #2151

Hi,

Can anyone help me to resolve this? It seems I set up everything fine, see blocks coming in, but placing an order fails with a "Private key is not known" message. The address does exist in my wallet and I do have bitcoin in it.

Here's the error:

c:\counterpartyd_build>counterpartyd order --from=<valid address> --get-quantity=10 --get-asset=XCP --give-quantit
y=0.0010 --give-asset=BTC --expiration=2 --fee_provided=0.0001


c:\counterpartyd_build>echo off
Traceback (most recent call last):
  File "c:\counterpartyd_build\dist\counterpartyd\counterpartyd.py", line 541, in <module>
    args.expiration, fee_required, fee_provided)
  File "c:\counterpartyd_build\dist\counterpartyd\lib\order.py", line 31, in create
    return bitcoin.transaction(source, None, None, fee_provided, data, test)
  File "c:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 295, in transaction
    transaction = serialise(inputs, destination_output, data_output, change_output, multisig=multisig, source=source)
  File "c:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 174, in serialise
    private_key_wif = rpc('dumpprivkey', [source])
  File "c:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 69, in rpc
    raise exceptions.BitcoindError('{}'.format(response_json['error']))
lib.exceptions.BitcoindError: {'message': 'Private key for address <valid address> is not known', 'code': -4}


Anyone got any ideas?

PhantomPhreak (OP)
Sr. Member
****
Offline Offline

Activity: 476
Merit: 300

Counterparty Chief Scientist and Co-Founder


View Profile
February 04, 2014, 12:54:50 PM
 #2152

Hi,

Can anyone help me to resolve this? It seems I set up everything fine, see blocks coming in, but placing an order fails with a "Private key is not known" message. The address does exist in my wallet and I do have bitcoin in it.

Here's the error:

c:\counterpartyd_build>counterpartyd order --from=<valid address> --get-quantity=10 --get-asset=XCP --give-quantit
y=0.0010 --give-asset=BTC --expiration=2 --fee_provided=0.0001


c:\counterpartyd_build>echo off
Traceback (most recent call last):
  File "c:\counterpartyd_build\dist\counterpartyd\counterpartyd.py", line 541, in <module>
    args.expiration, fee_required, fee_provided)
  File "c:\counterpartyd_build\dist\counterpartyd\lib\order.py", line 31, in create
    return bitcoin.transaction(source, None, None, fee_provided, data, test)
  File "c:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 295, in transaction
    transaction = serialise(inputs, destination_output, data_output, change_output, multisig=multisig, source=source)
  File "c:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 174, in serialise
    private_key_wif = rpc('dumpprivkey', [source])
  File "c:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 69, in rpc
    raise exceptions.BitcoindError('{}'.format(response_json['error']))
lib.exceptions.BitcoindError: {'message': 'Private key for address <valid address> is not known', 'code': -4}


Anyone got any ideas?



You need to temporarily unlock your Bitcoind wallet.
halfcab123
Full Member
***
Offline Offline

Activity: 224
Merit: 100

CabTrader v2 | crypto-folio.com


View Profile
February 04, 2014, 01:05:29 PM
 #2153

Would there be a way to transfer all current XCP holdings on the entire network to a newly designed protocol that sits on top of ethereum ?

DayTrade with less exposure to risk, by setting buy and sell spreads with CabTrader v2, buy now @ crypto-folio.com
uccoins
Newbie
*
Offline Offline

Activity: 32
Merit: 0


View Profile
February 04, 2014, 01:07:43 PM
 #2154

Hi,

Can anyone help me to resolve this? It seems I set up everything fine, see blocks coming in, but placing an order fails with a "Private key is not known" message. The address does exist in my wallet and I do have bitcoin in it.

Here's the error:

c:\counterpartyd_build>counterpartyd order --from=<valid address> --get-quantity=10 --get-asset=XCP --give-quantit
y=0.0010 --give-asset=BTC --expiration=2 --fee_provided=0.0001


c:\counterpartyd_build>echo off
Traceback (most recent call last):
  File "c:\counterpartyd_build\dist\counterpartyd\counterpartyd.py", line 541, in <module>
    args.expiration, fee_required, fee_provided)
  File "c:\counterpartyd_build\dist\counterpartyd\lib\order.py", line 31, in create
    return bitcoin.transaction(source, None, None, fee_provided, data, test)
  File "c:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 295, in transaction
    transaction = serialise(inputs, destination_output, data_output, change_output, multisig=multisig, source=source)
  File "c:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 174, in serialise
    private_key_wif = rpc('dumpprivkey', [source])
  File "c:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 69, in rpc
    raise exceptions.BitcoindError('{}'.format(response_json['error']))
lib.exceptions.BitcoindError: {'message': 'Private key for address <valid address> is not known', 'code': -4}


Anyone got any ideas?



You need to temporarily unlock your Bitcoind wallet.

I got stuck on this for a while, to unlock the Bitcoind wallet the command I used was:

bitcoind walletpassphrase *yourpassphrasehere* 600

where 600 is the number of seconds I chose to unlock it for
prophetx
Legendary
*
Offline Offline

Activity: 1666
Merit: 1010


he who has the gold makes the rules


View Profile WWW
February 04, 2014, 01:17:50 PM
 #2155

Congrats everyone for the successful burn period. I expected it would hit 3k BTC, but less is better (for us). Can't wait for the GUI wallet to be out.

I enjoyed taking all the trouble to get counterpartyd set up and do all the stuff. I am a non-technical guy and usually its just click qt for me.

Sorry but we have MasterCoin already.  Huh

https://bitcointalk.org/index.php?topic=265488.0

Somebody was already getting the jitters - reason for his sell off?

you should have made a bet with me, i would have bet you that it would be lower than 3k but over 1k, bummer
Alias
Full Member
***
Offline Offline

Activity: 127
Merit: 100

Money be green


View Profile
February 04, 2014, 01:39:29 PM
 #2156

Very interesting. Could be very useful for average users.
Just one question now, how about there's a reorganization after a checkpoint is setup? There has to be a scheme to invalidate the checkpoint in a short time. Maybe associate the checkpoint with the block hash.

Do you mean that you can only "unlock" the checkpoint with the actual latest block hash? Interesting.

Could I suggest a very crude "solution" - the checkpoint doesn't necessarily need to be the very latest snapshot of the Counterparty system. If the checkpoint was always at least even 1 hour old (6-ish blocks ago) the likelihood of a reorganization affecting blocks that far back would be incredibly low.

Also, since the Counterparty Checkpoint DAC runs across multiple machines and a block-chain reorganization is a local client occurrence, the DAC could actually determine when your bitcoind requires a reorganization and postpone the rolling out of the checkpoint.

In times of change, it is the learners who will inherit the earth, while the learned will find themselves beautifully equipped for a world that no longer exists.
mtbitcoin
Legendary
*
Offline Offline

Activity: 876
Merit: 1000


Etherscan.io


View Profile
February 04, 2014, 01:53:16 PM
 #2157

Very interesting. Could be very useful for average users.
Just one question now, how about there's a reorganization after a checkpoint is setup? There has to be a scheme to invalidate the checkpoint in a short time. Maybe associate the checkpoint with the block hash.

I don't think the block reorganization should be an issue with a partially updated downloadedable counterparty db. Because counterpartyd will just pick up from the last point left off and the reorganization will follow through from where it left off. Can someone further comment of this?? Alternatively the db snapshot can be taken earlier after a certain period of blocks have passed. While not exactly an ideal solution, but when combined with a checksum perhaps this should be workable stop gap solution

I have been been rebuilding the db multiple times the last few days and I must say it is time consuming

Cheers

EtherScan::Ethereum Block Explorer | BlockScan::Coming Soon
PhantomPhreak (OP)
Sr. Member
****
Offline Offline

Activity: 476
Merit: 300

Counterparty Chief Scientist and Co-Founder


View Profile
February 04, 2014, 02:04:21 PM
 #2158

Very interesting. Could be very useful for average users.
Just one question now, how about there's a reorganization after a checkpoint is setup? There has to be a scheme to invalidate the checkpoint in a short time. Maybe associate the checkpoint with the block hash.

I don't think the block reorganization should be an issue with a partially updated downloadedable counterparty db. Because counterpartyd will just pick up from the last point left off and the reorganization will follow through from where it left off. Can someone further comment of this?? Alternatively the db snapshot can be taken earlier after a certain period of blocks have passed. While not exactly an ideal solution, but when combined with a checksum perhaps this should be workable stop gap solution

I have been been rebuilding the db multiple times the last few days and I must say it is time consuming

Cheers

counterpartyd regularly checks for blockchain reogranisations in the last ten blocks (I just changed this), so that's right.

How are you rebuilding the DB, mtbitcoin? In the vast majority of cases, you just need to run 'counterparty.py reparse', and that takes only about 90 seconds on my i5. (Are you still running on develop? master is much slower, with its 'purge' function.)

EDIT: missing words
nakaone
Hero Member
*****
Offline Offline

Activity: 742
Merit: 500


View Profile
February 04, 2014, 02:20:31 PM
 #2159

well maybe i am wrong but

CONGRATULATIONS TO YOU FOR THE FIRST DECENTRALIZED  FINANCIAL MARKET IN CRYPTOCURRENCIES


2014 will be the beginning of cryptofinance and no matter where this ship is going you were the first who realized it
mtbitcoin
Legendary
*
Offline Offline

Activity: 876
Merit: 1000


Etherscan.io


View Profile
February 04, 2014, 02:22:35 PM
 #2160


How are you rebuilding the DB, mtbitcoin? In the vast majority of cases, you just need to run 'counterparty.py reparse', and that takes only about 90 seconds on my i5. (Are you still running on develop? master is much slower, with its 'purge' function.)

EDIT: missing words

Latest Develop commit. I overwrite the files and rerun. But like I PMed you earlier, I was running into some issues with develop branch on Windows and have been switching back and forth from the version 4 vs 6 db trying to make sense of things. The lastest DB rebuild from scratch appears to have resolved the issue though.

Another reason, i am currently using the develop branch because the db on this one excludes non counterparty transactions from the transactions table


EtherScan::Ethereum Block Explorer | BlockScan::Coming Soon
Pages: « 1 ... 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 [108] 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 ... 661 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!