On [this medium post](https://medium.com/@nicolasdorier/hf-and-sf-for-libertarians-1c8d4b68372d#.la65bgj4h), I maintained the following:

• A soft fork can't violate the Non Aggression Principle (NAP)
• A hard fork does not either, but service provider might violate it if not being careful by switching chain without your consent

On twitter piotr seemed to disagree, given the 140 limits I want to better discuss it here.

I think that modifying any incoming transaction with Bitcoin core to enforce LowS would be better than just blocking HighS.

I am even tempted to code a fake node who does exactly that. Do you think it would help ?

[If you are a dev in the list:]

Today I worked on a small website so core devs can upload easily their thoughts about the block size and present it to the community.

Core devs, please submit your thoughts (or at least what BIP you approve/disapprove) for each of those BIPs.
You need to submit a formatted message signed with your PGP key to edit your profile, I am using PGP pubkeys I found in bitcoin.org github.

Please let me know of any dev participants to add in this matrix, as well as other complete proposal I forgot.

If you are a dev in the list:

• Click on your name in the main page
• Click on Edit
• Submit a PGP signed, formatted message (HTML accepted) with your approval/disapproval and opinion on each BIP as in the example

If you don't have time, at least tell us what you reject completely and what would you be ready to approve.

Url : http://bipsxdevs.azurewebsites.net/
Github : https://github.com/NicolasDorier/BIPxDevs
Sample of message signed : https://aois.blob.core.windows.net/public/BlockSize/DevsPost/zsample.sig

Hope it help,
(Let me know if it breaks, I am using a small free website of Azure with quota limits )

The double threshold mecanism ensure that a BIP have approval before rolling out.
However, currently before any voting take place, we can get in the mess of today about which BIP to plan for activation.

Why not having a way for miners to informally vote to several BIP at the same times (where core devs would filter demands of proposal based on the quality of BIP, and of its PR), then when the vote is done, plan the switch at a specific date "manually" (without double threshold), or with threshold activation.

We can :

Informal Vote (no double treshold activation) => Plan (new bitcoin release including the bip) => Vote (threshold activation)

This is my understanding that most miners would agree to a kick the can solution overnight, without discarding another potential long term solution.
However, they have no way to express such interest right now, so we get this noisy environment where everybody try to talk louder to get heard.

BIP62 mentions that transactions that want to get malleability enforced in blocks should be in version 3.
I am puzzled, because I see nowhere in the bitcoin source code where the check against v3 is done.

Also

In transaction.h :

static const int32_t CURRENT_VERSION=1;

With

bool IsStandardTx(const CTransaction& tx, string& reason)
{
    if (tx.nVersion > CTransaction::CURRENT_VERSION || tx.nVersion < 1) {
        reason = "version";
        return false;
    }

Means that if the version of the tx is different from 1 then the transaction is not standard.
So, at the end of the day, contrary to what BIP62 announce, there is no tx version 3 right ?

The spam experiments of the last two days was fine but small, and can't give us lots of answer on longer term about blocks being fulled.
I'm proposing to provide a Bitcoin site #SpamTheBlockchain as a Service and throw it to all redditors, so we get fixed about what will happen.

I will give redditors an address that they can fund to automatically spam the blockchain. (UTXO and Transaction explosion)
I expect the spam experiment will be order of magnitude bigger in space and time. (compared to the 2 last days)

At the same time, I expect providing real time charts about what is happening. (hopefully with the help of laurentmt)

Surely, if something big happens I will cut down the service.

The current debate about the block size is hurting everyone, and provoke lots of uncertainty about bitcoin and, rightfully, impact future investments.
If we can't reach consensus, I think it will provoke a split of Bitcoin (XTCoin versus Bitcoin), which is to my mind, the equivalent of a nuclear disaster to this space.

Every bit of data which can help to make the mind of everybody about the real effects of full blocks will, to my hope, unlock the situation.

Before working on it, I want first your impression about this idea.
Before you yell about any disaster that might or might not happen as a result of this experiment, I will point out that the current real disaster is today's lack of visibility on the future of Bitcoin by the conflict about block size.
I hope to bring some objective light which will help to find a consensus.

I am developing a SPV wallet for NBitcoin, so I was looking at the best practices to protect privacy.
I've read about some flaws about the current spv wallets, so I'm trying to not make the same mistakes.

I read this paper : http://eprint.iacr.org/2014/763 (actually, only the "OUR PROPOSED SOLUTION" interested me)

But it seems flawed, because it disregard completely the fact that bloom filter with a flag different to UPDATE_NONE will be modified on the remote peer.

So imagine I calculate 500 addresses and create a new bloom filter with fp = 10%.
Since it will be updated each time a matching scriptPubKey is detected because the outpoint will be added to the filter, the fp rate will increase with time.

If my client have 30 of such tracked outpoint, then the attacker will have received 270 false positive.

But since I need to recreate the filter to bring the fp down to my expected value to free my bandwidth, the attacker can take my two filters, and see which outpoints match both filters at the same time.
And with very high confidence, he will know which outpoint belongs to my client.

So I was thinking about using UPDATE_NONE, and, for each P2PKH I am tracking, adding the Hash and the public key to the filter. (similar to what bitcoinj does, afaik)
But then I fall into this problem (In summary, the attacker use the fact that the filter match both the hash + the public key blob to know with quasi-certainty which are the client's addresses, which can be mitigated only by increasing considerably fp rate)

So now, I'm stuck...

Any address/link/input/advices ? (Not making a SPV wallet not the right answer though)

UPDATE:

I think updating the filter when, by monitoring, I see that the fprate is going above a certain treshold. The privacy will only leak when I switch the filter, which should be rare, and only for the unspent outputs which stay accross both filters, what do you think ?

UPDATE2, Solution:

I will create a filter with (1000,0.0005,tweak) filled with 1000 lookahead keys + tracked outpoint. The number of tracked outpoint should relatively be small not to change the effective fp too much.
I will keep all the filter's parameters constant as changing any of them will leak addresses.
Time to times I will need to refresh the filter because of false positive outpoint polluting and making the effective fp too high. At this point, the tracked outpoint will leak.
Since this is rare occurence, when it happens, I will simply drop the connection to the peer and connect to a new one.

At 900 used key, I will renew the filter to get 2000 lookahead and change parameter to (2000,0.0005,tweak2), when doing so, I will drop connection to all existing peers. (so the first 1000 addresses does not leak)
I'm using the same algorithm than bitcoind to not connect to nodes in the same "network group", so it should mitigate the odds that the new peer is controlled by the same entity.

I can't just create a second filter with the new addresses + outpoint as specified in the paper, because I would need to connect to a higher number of nodes. (if I end up with 100 different filters, I need 100 connection to nodes)

I noticed that fetching blocks over the bitcoin protocol is slow in my setting.
My node is in my local network which have over 100MB speed with my dev computer.

I find no way of making it better, and I'd like your advice, here is my finding:

• Average Speed Achieved : 5MB/s
• Max speed Achieved (ponctual) : 15MB/s
• Fetch strategy : getdata of 50 000 blocks, Tip to Genesis
• Client's socket receive buffer is never full (indicate bitcoind does not send fast enough)
• Disk IO and CPU not capped
• When the rcv buffer of the client is empty, it takes 100ms with low variance before new data come
• Using 2 connections instead of one for fetching blocks speed things up a little bit (7.5MB/s average)

I tried to play with receive and send buffer on both the bitcoind and the client code, no effect.

I noticed that the 100ms time it take for my buffer to be filled again must come from ThreadMessageHandler.

However by reviewing the code, I have seen no mistake : if the send buffer of the bitcoin node is not full, I should not experience any 100ms delay.
Once again, trying to change the buffers size of bitcoind had no effect.

Any idea ?

My alternative is to parse the blk directory over SMB, which go near 75MB/S.
But this is a fragile solution I'd like to avoid.

I am currently reading the Road of Serfdom of Hayek.
This is, as this forum told me before I bought, a marvelous book I do not regret one instant buying.

I just have one question. Hayek defines very well what are ultimately the effect of restrictionism/protectionism on markets, and the root of what caused it. (Namely, the perceived injustice of labor being outdated by technological progress)

But there are some subjects, in the book, which are not a lot discussed in depth by Hayek, which, to me, seems in contradiction with what he is preaching.
He seems favorable to minimum wages, but also for social services around insurances, but do not explain clearly his rational.
Insurances and wages are part of the market system. Insurance is a market of risk and wages part of the labor market.
A minimum wage can be seen as a restriction of entering the market for labor whose value is below it. (Milton Friedman)

I don't understand how he can rationally be against protectionism and restrictionism while being in favor of minimum wages and public insurance services.

Is there any writing where he talks about these subjects more deeply ?
I also want to know how his vision evolved until he died, Road of Serfdom being one of his first book.

Mon API bitcoin prend le jour...
Exemple de code pour recupérer les coins que vous pouvez dépensez, construire votre transaction localement, et broadcast le resultat en C#.

var client = new QBitNinjaClient(Network.Main);
var me = BitcoinAddress.Create("youraddress");
var balance = client.GetBalance(me, true).Result;
var coins =
    balance
    .Operations
    .SelectMany(e => e.ReceivedCoins)
    .ToArray();

TransactionBuilder builder = new TransactionBuilder();
var transaction =
    builder
    .AddCoins(coins)
    .AddKeys(new BitcoinSecret("yourkey"))
    .Send(BitcoinAddress.Create("your destination"), Money.Coins(0.1m))
    .SendFees(Money.Coins(0.0001m))
    .SetChange(me)
    .BuildTransaction(true);

var result = client.Broadcast(transaction).Result;
if (result.Success)//....
{
}

L'exemple montre la balance d'une addresse, mais il supporte colored coins (open asset), et aussi la creation/consultation de wallet avec quasiment le meme code. (voir la doc)
Ne l'utilisez pas pour de la prod, ça bouge pas mal

Mainnet server : http://api.qbit.ninja/
Testnet server : http://tapi.qbit.ninja/
Documentation : http://docs.qbitninja.apiary.io/#
Github : https://github.com/QBitNinja/QBitNinja
Nuget package : http://www.nuget.org/packages/QBitninja.Client

My guess is that those libs are statically linked to bitcoin executable.
However, will you distribute dynamic version of them ? if yes, do you have any approximate timeline ?

Après le ban progressif de nos liberté sous le nom de la sécurité (http://www.zerohedge.com/news/2015-03-23/fighting-war-terror-banning-cash),
Que diriez vous d'un bank run national au distributeur de billet en septembre 2015 pour fêter l’avènement de la nouvelle ère de la lutte contre le terrorisme, que monsieur Sapin a eu la sagesse d'inventer ?
Ca tente quelqu'un ?

Pour les aspirants devs, je viens de sortir la partie 2 de "Blockchain Programming in C#" https://bitcointalk.org/index.php?topic=973916

Happy coding,

[For others, you will have to wait 2 weeks, or wait someone who shares the link.]

Hello all,

As explained in https://bitcointalk.org/index.php?topic=926087.0, the next part of the book is out.
Special thanks to Bill Strait, a native english speaker, that corrected my english for the first parts.

He did not have time to do it for all chapter though, he will probably reformulate some of my sentences as time goes on. So expect some rough edge right with my english.

The second part is available for people that completed the first part challenge, or sent a tip to the book's address.
For others, you will have to wait 2 weeks, or wait someone who shares the link.

Here are the new parts:

• BIP39
• Arbitrary ownership
• Using the transaction Builder (Stealth, CC and normal payment)
• Colored Coins
• Ricardian contract
• Liquid democracy voting
• Proof of burn and reputation

Lot's of fixes,
Copy/pastable code instead of screenshots,

The part II explore some non-currency applications of the Blockchain.

The part III will concentrate on security aspect, while keeping in mind ease of development. (How to depends on third party API without trust relationship)

There will be probably some part about micro payment channel and coinjoin like schemes.

The link is http://blockchainprogramming.azurewebsites.net/

Happy coding,

I thought about how we could make a bitcoin address memorable.
Initially I thought about encoding a bitcoin address in base 2048, and reusing dictionaries of BIP39. (mnemonic)

However, a public key is 160 bit and doing so would require LOG(2^60, 2048)=15 words.
It is still hard to remember a public address.

Another way of doing so is publishing the address on the blockchain (in the output of a tx), and only remember : Block Height + Tx Index in the block + TxOut index

Such information can be encoded in 4 words with the help of a BIP39. (assuming height of 350 000, 10 000 tx per block, and 10 outputs by txout)

I intend to include that feature in the wallet I am developing, are you seeing any downside or alternative ? (Except a fork happening that would modify the address)

Not being satisfied about current wallets, I am developing my own.
This wallet is Power User Friendly, don't let your mom use it.

More coming soon...
Url : https://github.com/NicolasDorier/PowerWallet

This is not in a usable state yet, but I think the development of it can interest some people. I did not released binaries, so you have to compile it yourself.

Roadmap:
•Transaction Builder interface
•Colored Coin integration (Open Asset)
•Dark wallet integration
•Splitting/Consolidating coins
•Wallet management and tracking (mixing BIP38, BIP32, Stealth Address, normal address, colored or not, multi sig or not)
•Micro payment Hub
•Transaction Hub (spreading a transaction to multiple party for signing independently)

Specification:
•Depends on a third party server (RapidBase), which is open source and can be hosted by yourself. (no sync is needed for the client software)
•RapidBase will never store any key
•Wallet creation and transaction creation will not be abstracted by generic "send" and "receive" features. You'll get a Transaction Builder interface to select the coins you want to transact directly.
•Full of keyboard shortcut (like F3 for searching what some cryptic byte string represent)
•Windows only, no port will be done (NBitcoin and RapidBase client library are portable though, so they can be used for cross plateform wallet creation on top of RapidBase)

I will work heavily on the ergonomy of this tool. But I assume knowledgeable users.
A good tool is suited to his audience, and I did not noticed any wallet for power users.

Just to let you know, I am developing an open source Blockchain Indexer called RapidBase.

The reasons :

• Existing API provider are crap
• No API Provider support colored coins (Open Asset, except coinprism)
• No API Provider support Stealth Address (coming soon)
• They don't have nice REST interface
• They don't allow to make multi sig wallet easily
• When the sources are closed, innovation stays stuck at the API provider level

This work is experimental for now, so expect frequent breaking changes.
A nuget package for .NET, entirely integrated to NBitcoin is already out. (but not complete)
The nuget package will be compatible IOS, Android, Windows Phone, and Tablets in the future.
This will allow development of wallets on multiple plateform with a common source code, while mitigating privacy concern by allowing people to host their own rapidbase server if they want.

RapidBase is a JSON API on top of NBitcoin.Indexer and depends on Microsoft Azure.

Github : https://github.com/OS-RapidBase/RapidBase
Nuget : http://www.nuget.org/packages/RapidBase.Client
Public instance : http://rapidbase-test.azurewebsites.net/

We'll write more about it in the future.

Now that redeem scripts can be arbitrary, I think OP_EVAL might find a new usage.

Imagine you create a redeem that can be proven by anybody knowing some secret OR owning a specific bitcoin address.

Script redeemScript = new Script(
    "OP_IF "
        + "OP_HASH256 " + Op.GetPushOp(secretHash) + " OP_EQUAL " +
    "OP_ELSE "
        + address.ScriptPubKey + " " +
    "OP_ENDIF");

Such script works fine if address is a P2PKH, however if address is a P2SH then the only condition to satisfy the ELSE branch is to know the redeem script of address.
This could be fixed with OP_EVAL by the following way. (assuming address is P2SH)

Script redeemScript = new Script(
    "OP_IF "
        + "OP_HASH256 " + Op.GetPushOp(secretHash) + " OP_EQUAL " +
    "OP_ELSE "
        "OP_DUP " + address.ScriptPubKey + " OP_EVAL" +
    "OP_ENDIF");

Sure, we could also use multi sig or public key ScriptPubKey directly in the ELSE branch, but they might not necessarily be known by the builder of the redeem script.

I am making this post, not for starting a debate on whether intrinsic value is important or not, but as an experience of thought about why, from an Austrian school perspective Proof Of Stake can't work.
I do not want to debate whether the austrian school is right or not, I want you to evaluate if, given my premises I reach a coherent conclusion.

When an Austrian is skeptical about Bitcoin, he points out the lack of "intrinsic value" in Bitcoin.
Since I don't like this term that is vague, I will borrow the term "use value" of Mises instead.

An Austrian argues that Rice, Tabacco and Gold have a purpose outside those of a medium of exchange.
You can eat Rice, you can smoke Tabacco, and you can make Jewel with gold.
The use value makes the commodity highly marketable, which develop it as a candidate to become a medium of exchange.
Then, if this commodity is durable, portable, divisible, uniform, non falsifiable knows as "characteristic of money", it develops naturally as a medium of exchange.

There is no doubt about the "characteristic of money" in Bitcoin, which are higher than any existing alternative.
However, for the Austrian, the lack of "use value" of Bitcoin means that it can't develop as a medium of exchange.

But there is a clear use value of Bitcoin : Bitcoin allows you to insert a row in the Blockchain.

Even if Bitcoin is worth nothing as medium of exchange, inserting a row in a database that is global, can't be censured and can't be altered has a value.
This is the "use value" of Bitcoin.
As you know, such database would offer perspective for multiple industries, not yet exploited but soon will be. (justice, finance, insurance, payment and remittance)

The utility of the blockchain is rarely opposed, but if you admit its value, from an austrian perspective you also give "use value" to Bitcoin, since you can't insert without fees.
Surely enough, individually you can give no fees but if everybody do it, miners would more and more be reluctant to insert you, and this will be even worse when there will be no block rewards.
Even an altrust miner will make you pay the fees, because if he does not, he will loose money and then would not be able to pay the electricity bill.
Meaning that on the whole, fees, and thus use of Bitcoin will be mandatory to make the Blockchain lives.

And if Bitcoin has use value and the characteristic of money, then it will develop as medium of exchange.
So, from Austrian perspective, you can't admit blockchain utility without seeing Bitcoin as an emerging medium of exchange.
If you want to stay coherent and Austrian, either you deny blockchain utility or you accept Bitcoin as a kick ass medium of exchange.

Now, lots have been said about Bitcoin mining being "wasteful", and that Proof Of Stake would be "greener". (see https://en.bitcoin.it/wiki/Proof_of_Stake and http://bitcoinmagazine.com/6528/what-proof-of-stake-is-and-why-it-matters/)

I argue that from Austrian perspective, if a crypto is not "wasteful" (implying Proof Of Work), it can't have any "use value" and thus thrive as a medium of exchange.

Let's imagine a currency like NXT on Proof Of Stake. (It should be noted that I know nothing technically on NXT, but I just need a plausible name for sake of clarity)
You will mine a block with a % of your holding. IE, if you hold 1% of all NXT, you'll have 1% of mining the block.

Like Bitcoin, you would earn a block reward + transaction's fees.

Now my question is : why would a payer include a fee in its transaction ?
If there is no cost in inserting a transaction in the blockchain, an altruist miner would accept to process all transactions without fees. (for the benefit of the network and for protecting his stake)
If such is the case, there is no "use value" for NXT, thus (from austrian perspective again) it would not develop as a medium of exchange.
In turn, the "Stake" of miners would not worth anything, collapsing the network.

However when mining is costly (proof of work), if the miner want to survive without block reward, fees will be mandatory to pay the bills.
As the payer, Bitcoin is useful because it is needed to insert in the blockchain. As the miner, it is needed because it cost them real work to insert in the Blockchain.

Note that this explanation is also coherent with the labour theory of value of Marxians, which argues that gold is valuable because it requires work to extract.

Imagine that you discover a fork condition between V1 and V2 of bitcoin core.
Surely enough, this should be reported to github, and test data must be updated.

However, I think an even better action is to deliberately provoke the fork.
Since the damage a fork would provoke depends on the number of people being on the wrong side of the fork, I think it is better to provoke the fork sooner than later on buggy implementations.

Another reason to deliberately provoke it, is that would-be full node implementers (people that would not want to depends on bitcoin core) would be notified immediately about their bad implementation, and will not leave it unaddressed.

What do you think ?