Possibly people are realizing that with no merchants accepting PPC there's little hope for the widespread adoption that would drive the price up.
The main purpose of PPC right now is to field test the proof of stake concept as a viable solution to establish network security. And that's what the analysis should focus on right now. As such it's a hedge against POW implemented in bitcoin. I don't expect merchants to adopt it anytime soon. I'm speculating that the lack of transparency in development causes developers to not bother writing the code that would allow merchants to accept PPC for actual commerce. And the lack of support from merchants causes investors to lose confidence in the currency as a long-term investment. ...so we're both right.  thats not a speculation, its a fact  |
|
|
|
and again: just another reason why u shouldnt buy a placebo |
|
|
|
does anyone knows if it's possible to compile cgminer with asic support ? i want to install it on ubuntu 12.04 server x86 so as soon i get mine i can plug it and run it if you find a way to compile nonexisting code, contact me! il pay good for such a solution. |
|
|
|
Am I the only one who makes comparisons between bitcoin addresses? Or do other people just paste & send without giving it a second look?
What are you comparing it to? You do understand there is a CHECKSUM BUILT IN. Take an address you own and leave off a letter, change the case of a letter, add a letter, replace a letter, etc and try to send a bitcent to it. The client won't let you. The address will be invalid. The odds that you could mistype or copy an address and it still end up being valid but wrong is less than 1 in 4 billion. no i think he dosnt... |
|
|
|
damn i hoped hes in jail forever, ah well atleast im allowed to dream justice would have been done if so  |
|
|
|
I'm sure this scenario has been thought of but can someone tell me why the following can't happen :
Scenario 1
1) A malicious user joins a mining pool
2) The mining pool dishes out some hashes to try - he doesn't get the "golden ticket" this time, but does get a share of the effort (as per normal)
Scenario 2
1) Same malicious user joins mining pool
2) Malicious user finds the winning hash but then does not report it back to the pool, but claims it for himself.
3) Mining pool loses out on the mining reward.
Thanks.
Scenario 1 happens always when you dont find the block and someone else (asuming none PPS system) finds the block (ur golden ticket) Scenario 2 isnt possible, the data ur hashing is connected with a "seed", it contains the address of the pools owner in case the resulting hash solves a block. therefore if u change this adress the whole hash is invalid. altough u can withhold it so pool dosnt find the block, but u only hurt urself. u can destroy PPS pools with that (i discussed this already with ckolivas, just search for it) but u have to pay for it and have enough hashing power. |
|
|
|
why not bitcoind validateaddress <Your Address Here> therefore u will see if u made a typo or not! |
|
|
|
im not worried at the use part, i would use it as a communitty currency.
i would appreciatte if you give me a step by step on how to make a new blockchain.
will it support MM (Merged Mining)  |
|
|
|
For the first few ASICS that get delivered is it more profitable to mine with it or auction it to the highest bidder?
depends on the bid usually mining of course! |
|
|
|
The account balance stuff is really just a sum of individual entries. If the node reorganizes its chain, it rolls back everything in the removed fork, and then applies whatever it finds in the new fork. This happens pretty often actually, but has no net effect, because for the most part, the two branches involved are very similar. In a double spend, one of the removed parts will not be found in the new branch, and will not come back.
In short, the numbers are always correct relative to the node's current idea of what the "best chain" is. And yes, it has been tested extensively, both on the testnet, and in reality.
thanks, so im asuming that bitcoind is matching tx's to an account and calculates the sum of it for the balance, what happens if i used move to transfer part of the funds? these things are stored in the wallet.dat therefor these shouldnt be invalidated right? is there some documentation about this? move does not involve the network at all, it just creates entries in the internal ledger. As such, they are not subject to rollback. This could be troublesome for you if you are using move in response to unconfirmed, or barely-confirmed, transactions. But it should be fine to use it for your own transactions. Example. I get a bunch of small payments from p2pool, but want to de-clutter my wallet. So, I use the raw API to gather a bunch of them up and send them back to their own address. But I use an account to keep track of my p2pool earnings, and now the system thinks I've just been paid again, so I use move to reduce my p2pool account by the same amount as the transaction that I just sent myself. This is safe because I know that I'm not going to double spend against myself. i would never accept 0 conf tx's. to rephrase this simple: account balance is based on 2 things -> tx's which can be unrolled due to blockchain fork/sync/resync/orphaning and move operation which are stored in the wallet and wont be unrolled. therefore with the example @ #1 if i would move 0.5 BTC away from this account after a double spend attack the account should have a balance of -0.5. so if a account has 1k tx's, everytime i request "getbalance account" all 1k tx's will be checked for existence and nothing will be cached/similiar? i hope it does check every tx and dosnt cache anything (like everything past 1k blocks). thanks for your help |
|
|
|
The account balance stuff is really just a sum of individual entries. If the node reorganizes its chain, it rolls back everything in the removed fork, and then applies whatever it finds in the new fork. This happens pretty often actually, but has no net effect, because for the most part, the two branches involved are very similar. In a double spend, one of the removed parts will not be found in the new branch, and will not come back.
In short, the numbers are always correct relative to the node's current idea of what the "best chain" is. And yes, it has been tested extensively, both on the testnet, and in reality.
thanks, so im asuming that bitcoind is matching tx's to an account and calculates the sum of it for the balance, what happens if i used move to transfer part of the funds? these things are stored in the wallet.dat therefor these shouldnt be invalidated right? is there some documentation about this? |
|
|
|
more than the atoms in the universe
this isnt true, to be corect it has been said "more than the visible atoms" which is a significant difference! but still, its not true |
|
|
|
i like this idea, watching |
|
|
|
|
Lets say i transfer 1BTC to 1PlsTryToDoubleSpend...
according to the daemon the account with this address has now 1BTC. lets asume someone is going to fork the chain and publishes the longer chain later for double-spending, will the balance of this account be 0BTC or 1BTC?
I know this wont happen still i would like to know about it.
Was this already tested @ testnet for example?
TL;DR:
How are accounts affected to a Double-Spend attack (forking the chain and if the chain is longer, publishing it)?
|
|
|
|
If u cant do it, tell me which ISO u need this seems to be winblows, right? |
|
|
|
you cant have 51 cons if the limit would be 50.
Well, sometimes it's above the limit. Default is 6 outgoing connections. Now look at this: 2013-01-11 14:39:46.769000 P2Pool: 17418 shares in chain (17422 verified/17422 total) Peers: 5 (1 incoming)
2013-01-11 14:39:48.734000 Lost peer 80.87.240.47:9333 - Connection to the other side was lost in a non-clean fashion.
2013-01-11 14:39:49.452000 Outgoing connection to peer 168.7.116.243:9333 established. p2pool version: 1100 '11.1-50-ga80f1ab'
2013-01-11 14:39:52.369000 Outgoing connection to peer 31.169.66.66:9333 established. p2pool version: 1100 '11.0-2-g0981bdf'
2013-01-11 14:39:52.556000 Outgoing connection to peer 80.218.174.253:9333 established. p2pool version: 1100 '11.1'
2013-01-11 14:39:52.806000 P2Pool: 17418 shares in chain (17422 verified/17423 total) Peers: 7 (1 incoming)
2013-01-11 14:39:53.024000 Outgoing connection to peer 76.93.79.221:9333 established. p2pool version: 1100 '11.0-2-g0981bdf'
2013-01-11 14:39:55.832000 P2Pool: 17418 shares in chain (17422 verified/17424 total) Peers: 8 (1 incoming)
alright il take it back, sry. |
|
|
|
i got 50 outgoing cons and got 423MB mean usage, so this isnt possible. well, if your limit is set to 50, have you had 51? conns arent limited with my p2pool. you cant have 51 cons if the limit would be 50. |
|
|
|
i got 50 outgoing cons and got 423MB mean usage, so this isnt possible. |
|
|
|
ravn_3pl,
AFAIK you're running a Virtual Machine with absolutely everything (except basic kernel and console access) cutted off. IMO it cannot be compared to results provided by people running it on real servers with many services, older but stable Linux kernel etc. running on same hardware all at once.
Why? We talking about Python, it is connected somehow to hardware running program that only run program that NOT use hardware (only ram and cpu)? I don't know, I am not Linux expert:) This may be related to: python version and/or Linux kernel version. Probably it needs more attention from forrestv or someone else able to investigate those memory leaks. kernel is irrelevant since python is managing the memory of p2pool. it only depends on which python version/build. |
|
|
|
|
Show Posts
