I'm undecided about the increase in block size and I'm absolutely not defending Gavin's approach to it.

I actually agree with Pieter Wuille on this message:

Here's a crazy hypothesis:

Maybe Gavin realised where we're headed and didn't like what he saw.

With proposals like the Bitcoin Lightning Network the blockchain could one day only be used for a handful transactions per day, for settling big balances between major offchain micropayment processors.

Maybe he didn't like that idea and is trying to scale the blockchain to avoid it becoming redundant.

If that was to be the case, then the detractors who claim bigger blocks will centralise the network don't realize that it's actually a potential fix for avoiding even bigger centralised offchain silos.

An unintended network fork that is not quickly addressed and resolved is pretty much the death of the coin.

Perhaps the OP is referring to a planned hard-fork, to introduce necessary changes that simply break the previous consensus logic. In that case of course it's a good thing.

A Bitcoin fork is like creating 2 space-time continuums (think Back to the Future movie). Each side of the fork will have a different version of reality, so you loose global consensus. It's a really bad thing when it happens.

It is actually possible, just not easy as of bitcoind 0.9.

The keyword you're looking for is watch-only address/wallet, and you can achieve it today with a fair amount of work that involves multipe RPC calls to bitcoind.

The good news is that bitcoind 0.10 will support watch-only addresses out-of-the-box.

That is not correct, not even close.
The estimated number of atoms in the observable universe (10^80) is 71 million trillion trillion times greater than 2^160.

In a nutshell: In theory it does weaken. In practice, it doesn't matter... yet.

Just spending from an address already weakens it, because it involves signing the transaction with the private key, which is why re-using addresses is a bad practice also from a security point of view (in addition to the privacy issue).

In practice there is no imminent danger when signing transactions and messages, because the computational effort required to derive the private key from the publicly available information is still prohibitively large, but further down the line there is the small matter of quantum computing, as Vitalik explained.

Having said that, the Merkle-Signature Scheme (MSS) is resistant to quantum computing, so it may well become adopted by cryptocurrencies well in advance of quantum computing availability.

Related References:

• Bitcoin Is Not Quantum-Safe, And How We Can Fix It When Needed
• Bitcoin vs. The NSA’s Quantum Computer
• StackExchange: Is it possible to weaken a bitcoin private key by “using” it elsewhere?

Edit: just wanted to add that, as you mentioned, K should never be reused, and a good random number generator should be used if you plan to sign a large number of messages.

Interesting startups. Good luck with the IPO!

You've been listening to Andreas on the Let's Talk Bitcoin podcast right?

If you haven't then do. He spend a significant portion of one episode describing such self-sustaining and replicating autonomous agents, paying for their own existence through cryptocurrency.

Very cool stuff, and something I'd have loved to have got into around 15 years ago, when I was doing my masters in AI, except there was no Bitcoin back then. Now I've moved on to even more interesting stuff

What a crazy day, that's all I can say.

I've tested and it works for me as well: https://blockchain.info/tx/13326d4e0aa8ed620d4d28d26810f4ac9ce75e508d84b218f281c681389abdbd

Great work OutCast3k! 

No worries, take your time.

Yeah, I've noticed that their github repo hasn't be touched in a while. Ping me when you patch the code and I'll give it a test on this side.

I've just tested it twice, switching the order of the signing keys between tests, and both transactions were successful.
Your fix works!

Now that P2SH output support that we talked about earlier would be the icing on the cake
Should I nudge the bitcoinjs folks about the issue or do you want to have a go at it?

OK, after going over a few tests with OutCast3k we think we nailed the issue.

In a nutshell: Currently the order of the signatures matters.

Our tests involved a 2-of-2 multisig address, which I created with 2 pubkeys (lets call them pub1 and pub2).

When spending from the multisig address, signing the transaction with priv1 first and priv2 second always failed when broadcasting (with TX rejected).
But when signing the same transaction in the opposite order, using priv2 first and priv1 secondly the broadcast worked OK.  

Thanks OutCast3k for spending a considerable amount of time in troubleshooting this!

Definitely progress, the transaction now validates after signing, but still TX rejected when broadcasting. I've PM'd you the signed tx hex.

I think btcmsia is talking about compressed public keys, not addresses.
When you 'validateaddress' a Bitcoin-qt v0.8.x address, what you get are compressed public keys ("iscompressed":"true") whereas coinb.in expects uncompressed ones.


In my case I'm trying to use coinb.in to create and use a 2-of-2 address, but I'm stuck. I've done all the operations below from coinb.in:

1 ) generated 2 sets of Bitcoin keys (so 2 addresses, 2 public uncompressed keys, and 2 private keys)
2 ) generated a 2-of-2 p2sh address using the public keys from step #1
3 ) sent 0.0022 BTC to that p2sh address

So far so good. The funds are in the p2sh address, with 12 confirmations as I type this.

This is where the problems begin.

When creating a transaction, it looks like it doesn't support sending to p2sh addresses  , so I can't send change back to the address that I just created, nor to any other p2sh address (I have tried a couple of them). It only generates the transaction hex when I use non p2sh addresses. That is a significant issue for me. I really need to send the change back to the same address.

Anyway, I decided to retrieve the BTC back to one of my non p2sh addresses, and I'm still stuck. Here's the steps I've taken:

4 ) generate new transaction using redeem script from step #2, sending 0.0021 to a normal bitcoin address and with 0.0001 fee. Transaction hex is generated successfully.
5 ) verify the transaction hex from step #4. the verification is successful, and the input and outputs look OK.
6 ) sign transaction hex from step #4 with first private key from step #1
7 ) sign transaction hex from step #6 with second private key from step #1
8 ) broadcast the transaction hex from step 7
"TX rejected"

I noticed that the signed transaction hex from steps #6 and #7 cannot be verified like the original transaction hex in step #5, with "Unable to decode" error. However when pasting those same hex strings to https://coinb.in/decode-raw-transaction.html it decodes them successfully.

Any idea what could be going wrong with this?

Define "replaced".

For all we know, whatever "replaces" Bitcoin in the future could be a higher-level protocol that "replaces" all cryptocurrencies (in people's minds), but actually uses their blockchains under the hood. Something like Mastercoin or similar. In that case people won't care if their transactions are done using Bitcoin, Litecoin, or... Rapecoin (really?) just like people today don't care whether their BitTorrent client uses TCP or UDP as long as it downloads their stuff.

One thing is for sure, Bitcoin currently has the advantage of the brand, everyone's talking about it.

As history has taught us time and time again, the best technology doesn't always win. I'm not saying that Bitcoin is based on poor technology, much the opposite, it's remarkable, but most people just do not care.

Anything that hopes to "replace" Bitcoin any time soon will need much more than some trivial technical improvements. In my opinion even POS might not be enough (and this coming from someone with a small stake in NXT).

The ability to profit from p2p networks and open source software (through micro-transaction fee donations) could be baked right into the transaction protocol, see this for a related idea.

I like OpenTransactions, and I also like this concept. I can also write one or two LOC in Java so I will keep an eye on your GitHub repo.

I couldn't care less in which way it happens, as long as it happens eventually.

The funny thing about you calling me a noob is that I probably started using Bitcoin a couple of years before you did (received my first 0.02 BTC in May 2011 to be exact, so feel free to correct me if I'm wrong). I don't consider myself an expert in Bitcoin (altough I have already been called one), but I also don't consider myself a noob. You should not judge a person by their forum registration date or number of posts.