new feature - bitcoin v.9

[Peter Lambert]

guys, you are off topic.

on topic: I'm surprised by the features. It is progress and the dev team certainly has a reason to go this way but to me it feels rushed after a rushed 0.8.2 that also got many people by surprise. I don't see why a CA should be used in Bitcoin. Is this a protocol extension? The return-address certainly is an extension but I don't see why this linking of transactions should be in the block-chain. A service could have an api to receive signed messages with return addresses for certain transactions (if you receive a transaction with id X, please send return to Y. Please confirm this signing with the key of address 1dice...). Will these payment requests be public? Will transactions reference these requests? Where can I read more details? Why not sign with keys? Where can I read what plans the devs have to integrate next?

Are these changes pull requests now? Are they well tested on the testnet?

All in all I would just want more and kind of earlier info. Everybody knows about pruning but this gets delayed over and over it seams while some surprise-features pop up with next releases.

*sigh*

You need some way to authenticate the payment blocks.  Despite their many, many flaws, the SSL CA system is still by far the best way we have to do that.  You can still use self-signed certificates if you want to.  Personally, I'm hoping that the growing public awareness of CA abuse will spur people to finally develop a better system.

No, this is not a protocol extension.  The payment system exists outside of the bitcoin network.

The information in the payment protocol (such as the return address) is not included in the block.

The payment protocol is the API for signed messages containing metadata about transactions.

The requests will only be public if one side or the other publishes them.

Pruning has not been delayed "over and over" in favor of trivialities.  There are prerequisites that needed to be followed.  The Ultra-prune branch in git, for example, didn't actually do pruning, it was a collection of work that needed to be done before pruning could be implemented.

I don't know much about namecoin, but could it be used for the certifications?

[kjj]

I don't know much about namecoin, but could it be used for the certifications?

Probably.  You can embed a certificate fingerprint in namecoin's database.

The problem is the client.  There is a whole big chain of trust that needs to be managed between the client validating the certificates, and the authority for them.

Also, note that namecoin is going to be absolutely terrible at mapping namespaces to real world entities.  If there is a big real world entity that you know about, odds are very good that someone else owns most variations on that entity's name and trademarks.

And then there is typo squatting/phishing.  We end up in a situation where users must be very carefully compare the namecoin token to be sure they are fetching the right fingerprint.  This is a rather modest improvement over carefully comparing the fingerprint itself.

PKI sucks, and key management in particular.  Anyone else remember the late 90s, when encryption was reclassified from "munition, not for export" to not-munition?  Real security depends not only on good math, but also on good practices.  Perhaps someone in the NSA realized that we had no hope of developing good practices, so they decided to let us distract ourselves with good math.

[Kamikazee]

Bitcoin v.9 is great im looking forward to how it plays out overtime

[Kamikazee]

Dont you guys agree with that?

[Lohoris]

Use a web wallet. Problem solved.

Not for web wallet. With exponentially growing blockchain size, it will become a problem for them very soon.

Of course not: a web wallet would host only a *single* copy of the blockchain for all its users, not one for each of them.

[yvv]

Use a web wallet. Problem solved.

Not for web wallet. With exponentially growing blockchain size, it will become a problem for them very soon.

Of course not: a web wallet would host only a *single* copy of the blockchain for all its users, not one for each of them.

Of course yes. They will need to double their storage every several month. Do not think that it will be for free.

[kjj]

Use a web wallet. Problem solved.

Not for web wallet. With exponentially growing blockchain size, it will become a problem for them very soon.

Of course not: a web wallet would host only a *single* copy of the blockchain for all its users, not one for each of them.

Of course yes. They will need to double their storage every several month. Do not think that it will be for free.

I have visions of sysadmins frantically purchasing new drive after new drive to add to their servers, all sitting empty.

Hint: with the current block size limit, a 1 TB drive will die of old age long before it fills up in 2032 (at the soonest).

[Mike Hearn]

We've changed the default client recommendation on bitcoin.org to be MultiBit, so new users should be downloading that instead. MultiBit syncs the block chain in a few seconds for new users, because it's an SPV client. The security model is stronger than a web wallet and not quite as strong as Bitcoin-Qt, it's somewhere in the middle.

Basically - as long as the majority of mining power is honest, MultiBit is secure. Caveat: unconfirmed transactions when you have a malicious internet connection, then, you may see bogus unconfirmed transactions that are garbage and will never confirm.

[TippingPoint]

Doesn't MultiBit still store private keys unencrypted by default, and require major gymnastics every session to encrypt then delete unencrypted version?

"all private keys are kept encrypted on your local machine (or on a USB stick)"
http://www.multibit.org/features.html

"Faster to synchronize - usually a minute or so"

But how does it work?  described here:  https://bitcointalk.org/index.php?topic=252937.0

[dree12]

10 GB block chain size is an issue.  We are only 4 years into the use of bitcoin with relatively low amount of transactions.  Fast forward 10-15 years once bitcoin is main stream, and block size definitely could become a major issue.  It would be nice if a "new" genesis block could be created every 5 years or so.  All the past transactions could be rolled up into an offline archive.  The block chain size also becomes an issue for mobile (phones) devices.  Nobody wants to download a 25-50 GB file before they can use their phone wallet.

Take into account that blockchain size doubled since early this year. If it continues to grow at same rate, in early 2017 it will exceed 1TB, in the middle of 2018 10TB, by the middle of 2020 100TB, etc.

No, this is not an issue at all  

I wonder what else doubles every year...

[yvv]

I wonder what else doubles every year...

If blockchain size doubles every half year, and hard drive density doubles every year, I wonder, who will finally win?..

[dree12]

I wonder what else doubles every year...

If blockchain size doubles every half year, and hard drive density doubles every year, I wonder, who will finally win?..

When measuring exponential growth, average block size is more useful than total block size. Since 2011, average block size is doubling only once per year.

[yvv]

When measuring exponential growth, average block size is more useful than total block size. Since 2011, average block size is doubling only once per year.

Its a pity that my disk does not know anything about average block size.

[dree12]

When measuring exponential growth, average block size is more useful than total block size. Since 2011, average block size is doubling only once per year.

Its a pity that my disk does not know anything about average block size.

Sorry if I did not make my point clear. I'll elaborate.

We are talking about the sum of a geometric series. However, this sum is not strictly exponential. The formula is proportional to (1−qⁿ)/(1−q), where q is the growth factor in average block size and n is the number of blocks. When n is large, the formula can then be approximated as qⁿ⁻¹. When n is small, however, this approximation is not successful.

Consequently, to predict future block sizes, we must take into account the fact that the future approximation does not currently hold. A better prediction is to use the ratios of q itself, which is the growth factor in average block size.

[TheButterZone]

Doesn't MultiBit still store private keys unencrypted by default, and require major gymnastics every session to encrypt then delete unencrypted version?

"all private keys are kept encrypted on your local machine (or on a USB stick)"
http://www.multibit.org/features.html

Ah, just downloaded and poked the .wallet files in ~User\Library\Application Support\Multibit with the TextEdit stick. They aren't in clear text anymore. Cool.

[ShadowOfHarbringer]

http://thegenesisblock.com/significant-merchant-improvements-planned-for-bitcoin-v0-9/

seems like innovation is continuing. what do people think? what should be added to v1?

Coin control.

Confirmed. Coin control.

[yvv]

When measuring exponential growth, average block size is more useful than total block size. Since 2011, average block size is doubling only once per year.

Its a pity that my disk does not know anything about average block size.

Sorry if I did not make my point clear. I'll elaborate.

We are talking about the sum of a geometric series. However, this sum is not strictly exponential. The formula is proportional to (1−qⁿ)/(1−q), where q is the growth factor in average block size and n is the number of blocks. When n is large, the formula can then be approximated as qⁿ⁻¹. When n is small, however, this approximation is not successful.

Consequently, to predict future block sizes, we must take into account the fact that the future approximation does not currently hold. A better prediction is to use the ratios of q itself, which is the growth factor in average block size.

Regardless the details upon which growth factor depends (you can't predict it precisely anyway), competition between blockchain size and hard drive densities is silly. Waste of resources. Bitcoin blockchain is just quick and dirty solution, and I hope, in the future, a crypto-coin will come out wich solves this problem in more elegant way.

[TippingPoint]

I am using Bitcoin Wallet by Schildbach on my Android tablet.  It is fast and cool, although I still don't know how it works.

Now I know how it works:
https://bitcointalk.org/index.php?topic=252937.msg2690447#msg2690447

And Schildbach is:
http://schildbach.de/

MultiBit by Jim Burton (lead developer) with Gary Rowe and Tim Molter (contributors), and Android "Bitcoin Wallet" by Andreas Schildbach, with both projects incorporating the innovative code from bitcoinj by Mike Hearn https://code.google.com/p/bitcoinj/

[Mike Hearn]

They're built using it, not inspired by it. bitcoinj is the module that handles all the communication with the Bitcoin network. The apps add a GUI on top.

[TippingPoint]

They're built using it, not inspired by it. bitcoinj is the module that handles all the communication with the Bitcoin network. The apps add a GUI on top.

Thank you.  I will fix it.  I was trying really hard to give everyone credit, and I still dicked it up.