Am I correct in thinking that the Bitcoin difficulty adjustment algorithm which dictates the target hash's difficulty value for blocks, where difficulty is adjusted every 2016 blocks, purely adjusts itself based on the current hashing power on the network?

Am I also therefore correct in guessing it does this so as to avoid having to use any external dependencies and thus any potentially centralised resources which could also be an attack vector such as referring to an external time server?

Ok, so how does that differ with regard to SHA-256 as I understand that NXT is pure PoS?

I'm very sure based on it's initial spec that Ethereum will be able to do this. However it is not a coloured coin on the bitcoin blockchain so I would like to exclude it from the topic of this thread.

Specifically I'm interested in whether coloured coins, mastercoin and counterparty can do this?

[EDIT: I've moved this thread to Development & Technical Discussion as it may be more appropriate there.]

Thanks for all this. Will take a look at the NXT links.

Asking about PPC specifically does the blockchain expect PoS then SHA-256 blocks in a set order of rotation or does one supersede the other based on criteria such as the number of available PoS wallets left open for mining dropping off?

How will the SHA-256 degrade over time?

I believe I read somewhere that Sunny King said he had a solution to centralised check pointing in PPC if so how does this work?

I understand that there are a few tool kits out there for coloured coins which run off of the Bitcoin blockchain, for example, coloured coins, mastercoin and counterparty.

Although I understand that the underlying mechanisms for each are different I am looking to find out more about the variety of custom blockchains and transaction validation rules that can be created with each.

For example:

    1. Could an altcurrency be created using any of these which uses demurrage in the same way that Freicoin does?

    2. Could an altcurrency be created using any of these which destroys coins in the same way that PPC does per transaction?

I didn't realise SPV mode had been implemented, this is much nicer.


I'm guessing here that Satoshi is referring to an attack that creates another Merkel tree with the same values that matches the Merkel tree within a given block, substituting in a transaction in place of the 'real' one and then feeding it to the node requesting it via a Sybil attack to make it look like the real version on the network? Have I understood that correctly?

"One strategy to protect against this would be to accept alerts from network nodes when they detect an invalid block" - does the Bitcoin network currently do this?

Yes, the keyframe idea would involve trust so therefore breaks the current security model; I would therefore class it as flawed. Thanks.

Yes, unspent outputs, that's the term I should have used. My objective here was to make the blockchain being used smaller for devices such as smart phones etc rather than relying on a trusted node, e.g. many mobile wallet providers give a view of the blockchain to the wallet client from a central sever that stores an entire copy of the blockchain, from what I understand.

In this instance I'm suggesting storing the entire transaction I guess (not thought this one through fully) as if it is in a previous block then trust that that transaction is valid is implicit (based on its depth in the blockchain).


What security does a smart phone wallet employ when it gets its view of the blockchain via its central server? This is a questions as I don't fully know the answer.

My thinking was that if you're using a keyframe block then at least you know all the nodes who've propagated it have checked its validity. Perhaps having it as a side chain may work better.


This is an issue of convenience versus file size and bandwidth. Perhaps this idea is infeasible or there are better possible solutions but right now for me at least I know the current blockchain size is causing problems on some wallets.

When you say "discarding older blocks" are you talking about just storing the UTXOs in the database?

I had an idea a while back and can’t see any major flaws with it from a technical perspective it so thought I’d get feedback here.

In an attempt to reduce blockchain size would it be possible to introduce ‘keyframe’ blocks to a blockchain which summarise the blockchain’s current valid transactions all in one block?

This block would have different validation rules to normal blocks, but in essence it summarise all the currently valid transactions across the entire blockchain.

So to pick a number – every 500 blocks a keyframe block is generated (about 3.4 days for BTC).

This means nodes only concerned with the current transaction balances need only store at most 500 blocks back to the last keyframe block. Nodes which wish to see the entire transaction history store the entire blockchain.

I've searched but cannot find a bitcoin.conf associated with that bitcoin-qt.exe from what I can tell. Perhaps I'm missing something?


Yes: I'm editing the shortcut, not the .exe. The shortcut is in the same directory as the .exe.


I'd prefer to do this without creating symbolic links if possible.

Tried that and windows 7 reports:


So looks like it can't handle the spaces without the quotes. I also expanded the double quotes around the entire string and got  a different error.

For some reason it does not raise any errors on:
C:\Program Files (x86)\Bitcoin\bitcoin-qt.exe \datadir=G:\Bitcoin
C:\Program Files (x86)\Litecoin\litecoin-qt.exe \datadir=G:\Litecoin

But still uses the same directories on C drive when loaded from the shortcut.

This question has been asked before but I cannot find a solution to my specific problem.

I have created shortcuts for both bitcoin-qt and litecoin-qt and pointed them at their respective data folders which I have copied from their original locations. However they wallet software run from the shortcuts is using the original locations for the blockchain data.

Original locations:
C:\Users\[username]\AppData\Roaming\Bitcoin\
C:\Users\[username]\AppData\Roaming\Litecoin\

Copied them to:
G:\Bitcoin
G:\Litecoin

Under Properties>Target for each shortcut I have then specified:
"C:\Program Files (x86)\Bitcoin\bitcoin-qt.exe" –datadir=G:\Bitcoin
"C:\Program Files (x86)\Litecoin\litecoin-qt.exe" –datadir=G:\Litecoin

However when the shortcuts are run the wallets launch and the original directory locations are still being used. I know this because I cannot move or edit the original directories when the application is running. If I exit, move the originals directories and restart the shortcuts the wallets try to re-download the entire blockchain.

I am using windows 7.

Thanks for this. Is there any application or scripting framework you could point me at to do this so I don't have to write my own software to broadcast a transaction with a message in it.

Thanks for this; can you point me somewhere where I can read up on how to do this?

Does anyone know if there is a way to write the message from the Bitcoin-QT command line interface then?

I thought that one could optionally send a short message (40 bytes) to be written to the blockchain with a valid transaction.

If it's possible how do I do this?

Could someone explain to me how the system of counterparty and coloured coins are different? From my limited understanding of both they seem pretty similar.

So NXT retargets but relative to what? Does this retargeting have external dependencies? For example I assume it's not relying on some external time server...

Thank you for this, its a very interesting point. Am I correct in thinking that PPC is SHA-256 hybrid in an attempt to rectify this ability to rewrite coin history if you were a large coin holder in the past?

I'm trying to understand different Proof of Stake (PoS) implementations as they exist in NXT and PPC. I've given an overview of what I've managed to find online so far, but have lots of gaps in my knowledge, can anyone help answer the questions below.

NXT
This uses a 100% PoS mining process so the likelihood of being selected as the next node to mine a block is dictated by how many coins a user has in their unlocked wallet divided by all the other coins in all the other unlocked wallets on the network.

I understand each NXT block is every 60 seconds – how is this enforced by the network?


PPC
This uses a PoS/SHA-256 hybrid, where the reliance on SHA-256 will degrade at a predetermined rate with time.

How is SHA-256 combined with PoS in PPC to generate blocks?

The likelihood of mining a block, for a given unlocked wallet, is dictated by the coin-age of the coins for that wallet, as long as the coins are over 30 days old (not sure how many blocks this is).

How is a specific wallet selected to mine the next block from all the wallets able to use their coin-age?

What is the average block time for PPC and how is this enforced?

With the gradual decrease in reliance on SHA-256 over time how will this affect block generation times?

The bottom post here makes mention of some bugs relating to spending PPC coin age. Can anyone elaborate on what it was?

http://bitcoin.stackexchange.com/questions/20007/how-does-proof-of-stake-mining-work

Do the windows and Linux versions of bitcoinQT use the same wallet.dat file; i.e. can I move the wallet.dat file from a windows machine to a Linux one and have bitcoinQT work with that wallet?

Same question for the directories and files containing the blockchain data; i.e. can I move all the directories and files from the associated bitcoinQT directory which has an up to date version of the blockcahin on a windows hot wallet to the associated bitcoinQT directory for a Linux cold wallet to get that wallet to see the latest view of the blockchain?