Ahh..

my bad..

I use a script to parse the block via RPC.

there is no getrawtransaction.. ?

In fact - no raw transaction processing at all.

Hi,

I have upgraded to the latest ppcoind

"version" : "v0.4.0ppc-beta", from getinfo.

And i am not receiveing any of the coins that are sent to my addresses ?

Is anyone else having issues.. ?

I'll take my chances.

Did try the whole 'some-file some-where' backed-up, etc etc .. but it just stressed me out, far more.



 

+200 character passphrase for brain wallet..

Took a couple of weeks before I was SURE i could remember it. Then boom. No USB keys, no files, no stress.

cheers.

Won't this affect Bitcoin's fungibility ?

One Bitcoin won't be the same as another Bitcoin.. since there will be tax to pay on the capital gain.

If you bought a BTC at $10 and another at $100, and now you wanted to spend one to buy a $100 shirt, when the price is 100$/btc.

The 2 bitcoins have different value now.. 

Is that what they are saying ?

do

# strip bitcoind

This makes it small again..

Excellent!!

Thank you..

It's playtime :-)

Say there are 3 miners in all.

2 have a hash power of 1. 1 has hash power 2. Making a total of 4.

Without changing his difficulty the powerful miner would get 50% of the blocks. And the total hash rate of the network would be 4.

The Big miner then sets his difficulty to x2, effectively making him mine at the same speed as the other 2 smaller miners.

Now he gets 33% of the blocks, the same as the other 2 miners. BUT - if his block is not considered more 'worthy' of extension because of it's higher difficulty, the total network hash rate is now only 3.. We have just lost 25% of the power..

I have looked at the p2pool documentation but have not found reference to the actual way the longest chain is calculated,.. and whether the higher difficulty is used in the calculation.. if someone knows I'm all ears!

IF it is the case that your custom difficulty affects your shares 'weight', then a higher difficulty would mean your share is more likely to be the one that is extended in any chain race, and so less lightly to be a stale.. (Unless the total of all miners average each other out in some way) ?

That can't be right.. When working out which chain is the one with the most work, the longest, and so which one to extend, a large miner's share with higher difficulty must be more important than a normal share.. Otherwise there is wasted work being done and the chain is weaker?

With regards to an incentive for large miners to increase their share difficulty, like (1 - Fee per share) in the document,

If a miner on p2pool sets a higher difficulty, his block effectively 'weighs' more than a normal share, and so is his share LESS lightly to be turned into a stale share ?


 

It's a Moving Average.. Looking at the code could be an Exponential Moving Average, which fits in with the whole, black hole, gravity well thing..

http://en.wikipedia.org/wiki/Moving_average

It just changes the blocktime per block, rather than every 2 weeks.

I would be interested in knowing if anyone can think of any Disadvantages to using a moving average as opposed to a fixed 2 week readjust time ?

Or Vice versa..
 

Is there some way of checking the entropy of a Human-Chosen phrase ?

Is there a denomination for 'Entropy' ?

Can one thing be said to be more entropic than another.. and if so, how do you calculate it ?

 

Any coins that are 'In the market' HAVE to be stored on the exchange.. They cannot be stored by you.

Otherwise there is no guarantee that the trade can be fulfilled. Basically that you will or even can fulfil your end of the bargain.

If you do want that - use Ripple, that's how it works.

Already a bit clearer..

No problem..

I am a bit of a java boy myself and will admit to having tried to convert your code already.. and failed.. ha!

It's quite obfuscated.. with lots of 2 letter variables, pointers and no comments!  (I'm a bit comments OCD..)

What perturbed me is that there are literally only 20 or 30 lines of pertinent code, so I thought it would be easy.

Is there any chance you could just write a very simple pseudo code explanation ? I would convert that to java. (and SHARE of course)

I have looked through the pdf but that too is just a bit - gruesome..

Sorry to hassle, I would just love to play with it a bit..

Thanks again for your contribution!

I agree with Exbuhe27, it is some kind of 'Simple Moving Average', to smooth out the HASH rate curve.

http://en.wikipedia.org/wiki/Moving_average

Whether it is a Simple, Cumulative, Weighted or Exponential average I'm not sure.

Looking at the algo, it seems similar to the Exponential Moving Average, since it has (1-a)^k which is 'like' the code he uses.. and seems to fit in with the whole 'Gravity Well' thing 

I have looked for the specific numbers he uses in the code,

https://github.com/megacoin/megacoin/blob/master/src/main.cpp#L1276
 
And the only place 0.7084 seems to appear is..

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.10.7822&rep=rep1&type=pdf

But no concrete answer as to why he chose those particular values..

OK. Hope you won't mind me throwing another idea to be kicked around.. kicked in.

I have another POW/POS Chimera Horse.

Let's say you have GHOST protocol branch selection in place. This uses the branch with the most POW as the deciding factor, stales included. This value would need to be normalised to a ratio value from 0-1.

Now you do the same calculation but instead of using POW you use the sum of the total BTC balances, POS, of all the accounts used in txns in the blocks of the various branches. This value would also be normalised to a ratio value from 0-1.

You then add these values at each node of the tree, and use a GHOST protocol that uses heaviest POW+POS branch selection. (That's why they are 'in some way' normalised values)

This way if you wanted to take over the network you would need a minimum 51% POW AND minimum 51% POS(of the recent txns in the blocks). Large/Medium stake holders might regularly perform a tiny txn (to themselves if necessary), simply to show their approval of a branch, by adding their not inconsiderable BTC balances to the POS heaviest branch selection process.

A user could send a TXN and include the hash of a block that HAD to be in the chain that this txn would eventually be added to. That way users would have some say in which branch to go for.

Because it's too slow ?

And you'd get lots of stale blocks.. ?

no problem.. 

Hi tromp,

Like the look of cuckoo.. Well done for coming up with it. Original work always gets an A+ in my book.

Sorry to ask for more -  - but is there any chance you could knock up a JAVA version ?

I would love to play around with it..

YaCoin first introduced the variable N scrypt.. Not Vertcoin.

As regard the FEES issue.. Once minting diminishes, I see that the fees will have to be VERY high to support a network as secure as bitcoin. And so, you say let's have a little inflation to make sure the Miners are always rewarded. I have circled around this issue for some time, as have many of us, I'm sure.

Have you considered a small percentage fee instead of a flat rate ?  So - let's say 0.1% fee per txn. Maybe 0.01%..

This is still much MUCH lower than can be achieved with other means.

And - you now don't need inflation to pay the miners. They will always be 'fairly' rewarded for their work.

The idea that crypto txn's should be free / very low regardless of amount, has always seemed wrong to me. You need to pay for a service. It won't work otherwise.

Expecting someone who is transferring 1 Billion $ to pay the same fee as someone who is transferring 1$, seems unsustainable to me..