This is exactly the 'rolling block chain' approach (option 3) I favored. These transactions do not need to be broadcasted, they can be made by miners themselves. Also you can add a rule that the inputs must be from blocks of say one year ago at least, then any miner can assemble the transaction and charge a fixed transaction fee. The downside is there is a slight chance that user transactions can conflict with it, but I think anyways there needs to be a way to cancel an unconfirmable transaction, so probably not a big issue.
Regarding block chain size, I observe there are a couple lines of possible development in this front:
1) Ultraprune in bitcoin (large downloadable checkpoint of unspent outputs)
2) Balance based ledger block (this approach seems to have been taken by ripple)
3) Relocating unspent outputs forward in block chain
I am favoring 3) because of ease of implementation. Overall I think the most efficient is probably 2) but it's a costly redesign for bitcoin.
|
|
|
|
|
Good job. Hopefully freicoin would start doing better. Right now it has zero market no one is buying while other altcoins are gaining against bitcoin.
|
|
|
|
Is there a profitable service on Litecoin?
I dunno - I don't follow alt-currencies as much as I should. Litecoin has a SatoshiDice-like thing doesn't it? I've noticed the market cap of Litecoins is reasonably high. I'd be happy to write the patch required and submit it as a pull request. Lets follow Mike Hearn's suggestion of just removing the limit and we can make it enable itself at some defined block # in the future. We can do that by just making the limit double every month, to give miners some time to adjust, and have the limit start growing in 4 months to give everyone time to upgrade. It'd be a great experiment and could really set Litecoin apart. They've always wanted to be the "silver" to Bitcoin's "gold": fast cheap and convenient transactions. Hey, I'd love to be proven wrong about this blocksize thing. They'd need to move to bitcoin v0.8 first and then hard fork otherwise it's pointless as it would hit the BDB limit. |
|
|
|
|
I am sorry regarding the name I already said it should be as it is, so let's move on.
As for checkpoint, I am not in a hurry to weaken it as it was the mechanism to defend the last known vulnerability. Eventually it would become not enforced but only advisory. But we are still far from there in my opinion.
|
|
|
|
We are invited by Bitcoin Foundation to the May 2013 Conference in California USA ( http://www.bitcoin2013.com/) for a panel discussion on altcoins. If any one of you is planning to go to the conference and is reasonably familiar with ppcoin's proof-of-stake concept and design, you are welcome to volunteer because I wouldn't be able to go. I can help to gather some talk points if there is volunteer to present ppcoin. Thanks in advance, |
|
|
|
PPC can't be that bad, it has been used by Apple before, no?  As to terracoin, I have never heard of anybody claiming it to be 'green'. It was just a simple bitcoin clone, not much else. There are a few candidates that maybe can claim to be green, ripple, qubic, timekoin etc., ripple being the most serious project along this direction. |
|
|
|
Is there going to be a client for windows or mac?
ppcoin-0.3.0-win32-setup.exe is for Windows. mac build is not supported right now. |
|
|
|
Why do you need special testnet there is testnet running.
ppcoind -daemon -testnet
You can mine some coins on testnet with cpu easily. Or you can ask me for them.
My main concern is the removal of check point system. My thought is that it would affect others using the test net for other things, or that a mix of clients using/not using check points might affect the tournament itself. However, if I am mistaken , it would certainly be easier to use the current test net.  [/quote] Testnet doesn't have auto checkpoint. Although I think it's hard to run on testnet as not many people would be interested. You can run the contest on mainnet with checkpoint just try to claim consecutive proof-of-stake blocks. Even with checkpoint it won't prevent you from going way above 6 of them if you can generate them fast enough. |
|
|
|
Sounds like a good plan.
I believe a special test net would need to be set up (remove check pointing and assign a new rpc / IP p2p port).
Possibly change the address version just to avoid confusion.
I will put the chain on cryptocoinexplorer.com
Why do you need special testnet there is testnet running. ppcoind -daemon -testnet You can mine some coins on testnet with cpu easily. Or you can ask me for them. |
|
|
|
|
listreceivedbyaddress does not indicate how much money you have in the wallet.
use getbalance and listtransactions to investigate the issue.
|
|
|
|
And I still contest your "most software companies have harsh punishments" assertion. I can't imagine any self-respecting programmer working in the conditions you previously described.
It depends ... if after the harshest punishment possible my salary is still better than the other safer code crunching job, I will To be honest I haven't heard too many companies dealing out harsh punishment for software bugs. Although I'd imagine for people out there working for large bonuses it could get impacted pretty badly. |
|
|
|
It appears this problem depends on the size of transaction index. Thanks Mark for the pointer. The maximum number of lock objects needed can be estimated as follows:
For Btree and Recno access methods, you will need one lock object per level of the database tree, at a minimum. (Unless keys are quite large with respect to the page size, neither Recno nor Btree database trees should ever be deeper than five levels.) Then, you will need one lock object for each leaf page of the database tree that will be simultaneously accessed.
For the Queue access method, you will need one lock object per record that is simultaneously accessed. To this, add one lock object per page that will be simultaneously accessed. (Because the Queue access method uses fixed-length records and the database page size is known, it is possible to calculate the number of pages -- and, therefore, the lock objects -- required.) Deleted records skipped by a DB_NEXT or DB_PREV operation do not require a separate lock object. Further, if your application is using transactions, no database operation will ever use more than three lock objects at any time.
For the Hash access method, you only need a single lock object.
For all access methods, you should then add an additional lock object per database for the database's metadata page.
The maximum number of locks required by an application cannot be easily estimated. It is possible to calculate a maximum number of locks by multiplying the maximum number of lockers, times the maximum number of lock objects, times two (two for the two possible lock modes for each object, read and write). However, this is a pessimal value, and real applications are unlikely to actually need that many locks. Reviewing the Lock subsystem statistics is the best way to determine this value.
|
|
|
|
Thanks for the tips, although this is probably not enough as it may cause chain fork again unless all nodes take the workaround? Just create the file named "DB_CONFIG" in the ".bitcoin" or "AppData/Roaming/Bitcoin" directory that contains the following: set_lg_dir database
set_lk_max_locks 40000
The default was 10000. You can monitor the lock usage using "db_stat -e". I've tested it on an old laptop with 0.3.24 and 0.5.0. Obviously it will work with alt-coins based on the Bitcoin & BDB code. The same file should go into the respective "testnet" subdirectories. Please don't omit the "set_lg_dir database" line. Without it you may corrupt the "_db.00?" and/or "log.*" files if you are unlucky and run the Berkeley DB utilities like "db_stat". With this line you will at worst get the error message from those utilities. Good luck. Edit: Oh, I forgot about the most obvious or non-obvious: restart the bitcoind/bitcoin-qt. |
|
|
|
Most of you have probably heard about the shenanigans in the Bitcoin block chain recently, where an incompatibility in client versions briefly forced an uncommanded fork in the block chain. The situation seems contained, but questions remain. Since most of the alts use a very similar block chain, and their clients are near copies of Bitcoin's, how vulnerable are they to this same problem, and what could realistically be done about it?
I am following the bitcoin issue since yesterday it looks like the problem is with pre 0.8 clients that uses berkeley db. I think almost all altcoins are still based on bitcoin 0.7 or earlier, except for terracoin, so yes we are probably affected. I am monitoring the situation closely right now and will give updates as I get a better handle of the problem. Stay tuned as I don't exclude the possibility of emergency patches for miners if there is immediate threat on block chain. |
|
|
|
At least he's working on it! Thanks for disclosing it to him first! Much appreciate by the community!
You are welcome rabbit Don't you feel a little dizzy looking at the price right now  |
|
|
|
Throwing some cold water here Terracoin has a serious vulnerability that I just disclosed to the dev yesterday. He's working on a solution right now but no Satoshi wouldn't have made such an elementary mistake as he knows bitcoin too well. Also I bet Satoshi moved on to interesting new ideas. If he'd want to just make bitcoin clones he would've just stayed in bitcoin |
|
|
|
|
Can someone post error messages in debug.log rejecting the bitcoin v0.8 mined blocks?
|
|
|
|
what is considered a micropayment? , or different question: what is the smallest amount possible to pay? wouldnt this just make the number of digits behind the dot less (0.0001 instead of 0.00000001)? I dont really understand most of this , probably should read more about it .. my guess would be a micropayment is the smallest possible amount you're able to send, so i just dont really understand "micropayment has to go" , if you are making micropayments bigger, they are still micropayments , no? i guess im wrong here and there..
It's true that ppcoin effectively only accounts to cent, although it can support upto uPPC (1 millionth) in calculations. This allows users to send amounts like 0.010001, so they still have some room for their 'micro-transaction communications'. Also makes it easier to lower the minimum txout value in a hard fork. By having a minimum send value enforced, it just means ppcoin does not support sub-cent micropayments. So far nobody has complained this to me, so I think really the impact to users is minimal. |
|
|
|
Regarding block chain size, I observe there are a couple lines of possible development in this front:
1) Ultraprune in bitcoin (large downloadable checkpoint of unspent outputs)
2) Balance based ledger block (this approach seems to have been taken by ripple)
3) Relocating unspent outputs forward in block chain
I am favoring 3) because of ease of implementation. Initial blockchain download is necessary only to verify that current UTXO set is correct. If that isn't your concern, you can just get current UTXO set and hope it is correct. So (3) solves approximately nothing. The best approach is for miners to maintain UTXO set in form of a tree and link it from blocks. This way anybody can do anything they want without even downloading the whole thing. You are too quick dismissing the 3rd option. If everyone gets current UTXO set and trusting other nodes for it what's the implication on security and decentralization? Where option 3) allows us stay true to the current security model where checkpoints and active part of the block chain guarantees your block index to be correct. |
|
|
|
Glad to see how PPC keeps moving on right direction and learning from btc mistakes. Few can do that. Any thoughts on how to avoid the absurd situation BTC is or will be in with it's massive block chain? Installing an official BTC QT client now days is not a small task because of the huge download requirements (and it's getting worst by the minute). I still believe that big files are fragile files. I only ask because I see the ugly trend in BTC, where the complete transaction data will be available for only the select few. Rest of us have to rely on bits of data made available via some "middleware" ("explorers"), controlled by those few... stinks like bank... hold on, *coin supposed to free us from the central control! Cheers! Regarding block chain size, I observe there are a couple lines of possible development in this front: 1) Ultraprune in bitcoin (large downloadable checkpoint of unspent outputs) 2) Balance based ledger block (this approach seems to have been taken by ripple) 3) Relocating unspent outputs forward in block chain I am favoring 3) because of ease of implementation. Overall I think the most efficient is probably 2) but it's a costly redesign for bitcoin. Regarding block size limit, it was put in there to prevent premature growth of block chain size. As you said, people have trouble doing the initial download because it's too intensive on the computer. We need more time for average PC to catch up to the job, to raise block size limit before that happens is going to make average node feeling the pain. The hardware more suitable for future bitcoin full node is: Terabyte SSD to accommodate the active part of block chain plus entire block index. Internet access preferably 100Mbps symmetric. This will allow bitcoin to begin competing against networks such as paypal in terms of transaction volume without sacrificing decentralization. It's a tough decision, we'll see what happens with bitcoin. There is speculations going on that if bitcoin delays raising block size limit then transaction volume is going to flow to litecoin because at the current limit litecoin can handle 4x the transaction volume of bitcoin (bitcoin needs to raise block size limit to 4MB to match litecoin). The problem is that litecoin would have the exact same issues bitcoin network has in this situation. |
|
|
|
|
Show Posts
