What's new in Bitcoin 0.9.X ,We ready upgrade
-
A new milestone in the development of the Bitcoin reference implementation has been reached, version 0.9.0. As a major version it introduces both new features and bug fixes.
The full list of changes is huge and it is too much to mention everything in this blog post. I will highlight a few prominent changes from a user perspective.
Payment requests
Payment requests are Bitcoin invoices. They were introduced (in BIP 70) to solve the limitations of Bitcoin URIs and provide a safe and flexible payment solution. For example a refund address is automatically provided to the merchant to be able to refund the order when something goes wrong. Payment requests can be also be cryptographically signed to make sure that the payment goes to the intended recipient.
The payment requests can be sent by a website (as a link) but also sent over mail or any other communication medium that supports file attachments. When opening a payment request is will be shown like this:
Signed and verified payment request
A signed and succesfully verified payment request will be shown in green
The payment request functionality in 0.9.0 is a first iteration. In upcoming releases the user experience and functionality will be fine-tuned. For merchants it is recommended to migrate to using payment requests as soon as possible. Various other Bitcoin wallets, as well as payment providers such as Bitpay have already added support.
Rebranding to Bitcoin Core
The rebranded splash screen
A long time ago the Bitcoin reference implementation was the only implementation of Bitcoin.
This time is long past and today quite a few alternative clients exist, which makes it ever more important to distinguish between Bitcoin-the-network and Bitcoin-the-software.
For this reason the Bitcoin reference client has been rebranded with 0.9.0. The new name is Bitcoin Core.
The name “Core†highlights the purpose of the software to run the core infrastructure of the Bitcoin network. It also describes the near-future direction of the project to encompass the core functionality instead of trying to be everything for everyone. Over the next releases, non-core functionality (such as the wallet) will be split off to different projects to allow independent collaboration and release cycles.
New receive coins workflow
The new overhauled receive tab
A more convenient workflow has been introduced for receiving coins. The Receive tab has been replaced with a form in which an invoice can be created.
Let’s say that you want to request a payment from someone. You can fill in the amount of coins requested, the label and a message for the payer. All of these attributes are optional, so it is possible to just request an address without entering any of these.
The invoice shown when requesting a payment
When finished, this invoice is immediately shown with a QR code and Bitcoin URI. All information can be easily copied to be pasted in a document or message. The QR code can be scanned with a mobile device.
These invoices will be stored in a list for later reference. Unlike receiving addresses which are kept forever, these invoices can be freely deleted. It is possible to get the full list of receiving addresses as before through Receiving Addresses… in the File menu.
Coin control
Coin Control is a new feature for advanced users that allows manual control over coin selection. Every time that you receive coins, a new unspent output is added to the wallet. These outputs (“coinsâ€) are combined as necessary for outgoing payments. Normally this selection process happens automatically and outside control of the user. With Coin Control, the user can select which unspent outputs to use as inputs to an transaction. It also makes it possible to control to which address the change will go.
Coin control information at the top of the Send tab
Coin control: Transaction input selection
Exercising manual control over coin selection allows for a degree of privacy by controlling which coins are used together, and thus what a third party looking at the block chain will see. It also gives insight into the inner workings of Bitcoin, such as the fee computation and the size of transactions which is nice for educational value.
Coin Control is disabled by default and can be enabled through the Options:
enable_coin_control
Enabling Coin Control in the Bitcoin Core Options Dialog.
Work on Coin Control has been going on for a long time as a separate patch. With the 0.9 release it has finally been integrated into the upstream repository.
-
I like the coin control feature (although it maybe overkill for most users).
And the payment requests feature looks nice.
-
0.9 need a new lib,it is protobuf-2.5.0 ,support paymentrequest.pb.cc
-
Looks like it would be a good idea to include the 0.9 client. in the NeoScript upgrade. If so we’d need to be testing those changes first, while the GPU situation works it’s way through.
Best to start a [Dev] development thread, upgrades aren’t really “Off Topic”
-
Re: Upgrade to Bitcoin Core 0.9.X
The other point is we usually wait for the Litecoin version, and patch with Feathercoin enhancements, are you suggesting moving directly to adding patched to Bitcoin core? That’s a lot more work and more complex to pull off…
-
Can we hold this off until after we’ve moved to Neo?
-
Are FTC and BTC the same ?
pruned version of CTransaction: only retains metadata and unspent transaction outputs Serialized format: - VARINT(nVersion) - VARINT(nCode) - unspentness bitvector, for vout[2] and further; least significant byte first - the non-spent CTxOuts (via CTxOutCompressor) - VARINT(nHeight) The nCode value consists of: - bit 1: IsCoinBase() - bit 2: vout[0] is not spent - bit 4: vout[1] is not spent - The higher bits encode N, the number of non-zero bytes in the following bitvector. - In case both bit 2 and bit 4 are unset, they encode N-1, as there must be at least one non-spent output). Example: 0104835800816115944e077fe7c803cfa57f29b36bf87c1d358bb85e <><> | \ | / version code vout[1] height - version = 1 - code = 4 (vout[1] is not spent, and 0 non-zero bytes of bitvector follow) - unspentness bitvector: as 0 non-zero bytes follow, it has length 0 - vout[1]: 835800816115944e077fe7c803cfa57f29b36bf87c1d35 8358: compact amount representation for 60000000000 (600 BTC) 00: special txout type pay-to-pubkey-hash 816115944e077fe7c803cfa57f29b36bf87c1d35: address uint160 - height = 203998 Example: 0109044086ef97d5790061b01caab50f1b8e9c50a5057eb43c2d9563a4eebbd123008c988f1a4a4de2161e0f50aac7f17e7f9555caa486af3b <><> / \ \ | | / version code unspentness vout[4] vout[16] height - version = 1 - code = 9 (coinbase, neither vout[0] or vout[1] are unspent, 2 (1, +1 because both bit 2 and bit 4 are unset) non-zero bitvector bytes follow) - unspentness bitvector: bits 2 (0x04) and 14 (0x4000) are set, so vout[2+2] and vout[14+2] are unspent - vout[4]: 86ef97d5790061b01caab50f1b8e9c50a5057eb43c2d9563a4ee 86ef97d579: compact amount representation for 234925952 (2.35 BTC) 00: special txout type pay-to-pubkey-hash 61b01caab50f1b8e9c50a5057eb43c2d9563a4ee: address uint160 - vout[16]: bbd123008c988f1a4a4de2161e0f50aac7f17e7f9555caa4 bbd123: compact amount representation for 110397 (0.001 BTC) 00: special txout type pay-to-pubkey-hash 8c988f1a4a4de2161e0f50aac7f17e7f9555caa4: address uint160 - height = 120891 -
Can we hold this off until after we’ve moved to Neo?
We just make some preparations, pass the boring time :)
-
ok then :D
-
move this post to Technical Development
-
move this post to Technical Development
-
I push my feathercoin technical architecture. This is a PowerPoint from my tentative plan.
-
I love the graphics design Liz!
+1
-
I push my feathercoin technical architecture. This is a PowerPoint from my tentative plan.
I also very much like, thanks +1
-
**Just Read this on Github: re: upgrade version 0.9.3 **
Warren Togami to litecoin
You have to understand that there is little point in releasing 0.9.3 as-is merely to match Bitcoin. This is because we worked hard to backport many of the key features of 0.9.x to our current Litecoin release 0.8.7.2 to such an extent that there is almost no benefit in upgrading. If we are going to take the risk of a major upgrade it better add actual features that users really want. At this moment I have 0.9.3 working without any known problems and I am working on backporting the most useful Bitcoin 0.10 features like watch-only addresses. A source-only alpha tree will be public within a few days.
â€"
Reply to this email directly or view it on GitHub.
-
I push my feathercoin technical architecture. This is a PowerPoint from my tentative plan.
Looks great Lizhi. +1
-
What’s the DPOS?
Also, that should be “Light/Dark Blockchain”
-
Also looks like Cryptonit will help us implement cross crypto exchange into the QT. The user just needs an account with cryptonit. The affiliate stuff will help feed the community bounty pool. I think they are also offering no fees for ftc withdrawals and deposits…
“If you are serious enough we can thing of removing deposit/withdrawal FTC fees, it will make absolutely free moving FTC coins between actual balance and trading balance.”
-
Wow that sounds awesome!!
-
If you had to describe feathercoin in one sentence, how would you do it?
I say “new core new dream” :)
