Topic: [ANN] [PPC] PPCoin Released! - First Long-Term Energy-Efficient Crypto-Currency - page 123. (Read 684839 times)

Gut feeling it's in the CreateNewBlock section, the version it was forked from would also help.

Was PPCoin based on a stable bitcoin release? If so, what commit id, so I can get a diff of just the PPCoin change.

Alright thanks, just wanted to clear that up.

If anyone finds an easy setup to reproduce the memory leak issue please let me know. Thanks,

Repo is updated right before release builds are ready for pickup. This release is not mandatory so there is no rush.

One question, how long until the github repo will be updated. I'd like to start work on building the new client as soon as possible.

Weekly Update #4

• With Chris' debut of Bitparking PPC Exchange the week before, this week we have witnessed a mini episode of gold-rush, where difficulty is ramped from below 4000 to over 22000. At some point, I estimated that the network surpassed 1% of Bitcoin's hashing power. The peak was reached at block 6031, difficulty 22334. Currently we are back at around 16000. I would like to caution traders and investors to be aware of the risk involved especially during periods of high volatility in market. Remember ppcoin is still an experimental chain and lots of different risks are possible.
• There are a few reports of high memory consumption of ppcoind in certain environment. I will search for a reproducible setup to help investigate this problem.
• It seems that our continuous target adjustment handles difficulty drop quite well. It's been only 2 days since peak difficulty and we are already at 72% of peak difficulty so the drop rate is reasonably fast.
• Bug fix release v0.2.1 is under testing and expected to be ready some time next week.

Have fun and next week!

Linux engine.redb.us 3.2.0-27-generic #43-Ubuntu SMP Fri Jul 6 14:25:57 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux


drwx------  3 andrew andrew 4.0K Sep 16 12:01 .
drwx------ 25 andrew andrew 4.0K Sep 14 14:08 ..
-rw-------  1 andrew andrew 848K Sep 16 12:03 addr.dat
-rw-------  1 andrew andrew 2.6M Sep 16 11:57 blk0001.dat
-rw-------  1 andrew andrew 2.7M Sep 16 11:57 blkindex.dat
drwx------  2 andrew andrew 4.0K Sep 16 11:57 database
-rw-------  1 andrew andrew  24K Sep 16 12:01 __db.001
-rw-------  1 andrew andrew 1.8M Sep 16 12:04 __db.002
-rw-------  1 andrew andrew  32M Sep 16 12:04 __db.003
-rw-------  1 andrew andrew 1.2M Sep 16 12:04 __db.004
-rw-------  1 andrew andrew 6.1M Sep 16 12:04 __db.005
-rw-------  1 andrew andrew  48K Sep 16 12:03 __db.006
-rw-------  1 andrew andrew    0 Sep  5 10:16 db.log
-rw-------  1 andrew andrew 1.3M Sep 16 12:04 debug.log
-rw-------  1 andrew andrew    0 Sep  5 10:16 .lock
-rw-rw-r--  1 andrew andrew   90 Sep  5 10:17 ppcoin.conf
-rw-------  1 andrew andrew 360K Sep 16 11:57 wallet.dat



pypool; custom modified.

I think it is linked to getwork/mining also.

My pool also calls:
-getblockcount
-gettransaction

and from time to time :
-sendtoaddress
-validateaddress
-getbalance

getwork calls CreateNewBlock, has that changed? The pool also called getdifficulty.

Ah that's probably why I don't see it on any of my nodes. Which RPC calls does the pool software call other than getwork? I don't see any change to getwork so I assume it's some other call causing this problem.

I see it on my pool as well. Running 64bit Linux it's at 4.6g. The exchange doesn't though, it's at 185m so I assume it's something mining related.

Andy, are you on linux or windows? Which miner/external software you use? And the size of your wallet.dat file?

I have same problem, after a few days im at 7.2G virt/5.4G Res

Andy

Hi coinotron,
  I have sent you a pm.

Hi Sunny
I've observed strange behavior of ppcoind running in Coinotron pool. After 3 days it uses 1.1 GB of RAM - much more than for example bitcoind (130MB).

I compiled the newest windows version: ppcoin-ppcoin-v0.2.0ppc-0-g09051bd.

There seems to be a memory leak somewhere.

There is a lot of "ERROR: BitcoinMiner : proof-of-work not meeting target" messages in debug.log.


Could you please look into it?

Hi dreamwatcher,
  This is most likely because abe needs to be aware that there is an additional timestamp field for ppcoin transactions. In ppcoin each transaction begins with a 32 bit unsigned timestamp.

Sunny,

More questions is regard to a block explorer.

Has the structure of the block changed?

The trouble I am having adapting ABE to PPC:

When the deserializer tries to parse incoming transactions as shown here: (the highlighted print statement was added by me for debugging)

def parse_TxIn(vds):
 
  d = {}
  d['prevout_hash'] = vds.read_bytes(32)
  d['prevout_n'] = vds.read_uint32()
  d['scriptSig'] = vds.read_bytes(vds.read_compact_size())
  print len(d['scriptSig'])
  d['sequence'] = vds.read_uint32()
  return d

Output is such:

vm@vm-VirtualBox:~/abe$ python -m Abe.abe --config abe-my.conf --commit-bytes 100000 --no-serve
2235787
Failed to catch up {'blkfile_number': 1, 'dirname': u'/home/vm/.PPcoin', 'chain_id': Decimal('1'), 'id': 17L, 'blkfile_offset': 0}
Traceback (most recent call last):
  File "Abe/DataStore.py", line 2267, in catch_up
    store.catch_up_dir(dircfg)
  File "Abe/DataStore.py", line 2301, in catch_up_dir
    store.import_blkdat(dircfg, ds)
  File "Abe/DataStore.py", line 2423, in import_blkdat
    b = store.parse_block(ds, chain_id, magic, length)
  File "Abe/DataStore.py", line 2455, in parse_block
    d['transactions'].append(deserialize.parse_Transaction(ds))
  File "Abe/deserialize.py", line 94, in parse_Transaction
    d['txIn'].append(parse_TxIn(vds))
  File "Abe/deserialize.py", line 50, in parse_TxIn
    d['sequence'] = vds.read_uint32()
  File "Abe/BCDataStream.py", line 71, in read_uint32
    def read_uint32(self): return self._read_num('  File "Abe/BCDataStream.py", line 111, in _read_num
    (i,) = struct.unpack_from(format, self.input, self.read_cursor)
error: unpack_from requires a buffer of at least 4 bytes



The red highlighted number is the length of the output it is receiving for ScriptSig (from the print statement I added), basically the rest of the  blk0001.dat file.

The error comes up (buffer need to be at least four bytes) because the read_cursor has already hit the end of the file. (At least that is what I believe).

My eyes are getting buggy from looking at PPC source code, maybe you can make this simple.

What structure changes has there been in the block, at least in the way TxIn is stored?


FYI, I removed all the other chain identifiers in abe, and that is why it identified the chain as "1" as it is the only chain ID in abe.

CHAIN_CONFIG = [
    {"chain":"PPcoin",
     "code3":"PPC", "address_version":"\x37", "magic":"\xe6\xe8\xe9\xe5"},
    ]

yes. coinage is accumulated regardless of the wallet being online or not. What matters is the time the corresponding input transaction was incorporated into the blockchain.
However, right now I think the maximum time you can accumulate per transaction is 90 days:


the second line takes the minimum number of seconds when it computes the coinage (CTransaction::CheckProofOfStake), which is either (nTime-txPrev.nTime) or STAKE_MAX_AGE, whatever is lower.

Thus if you stash away your stake wallet, put it online every 3 months to redeem your stake.

if a wallet is offline when it's PoS life is reached, as soon as it goes back online it signs accordingly and generates the block right; kinda backdated?