Topic: Bitcoin Core 0.15.0.1 Released - page 4. (Read 30643 times)
the new version is much more better than the old.Now it is much more faster [so, there is no room for waiting],and the new features makes it much more elegent.i am very glad that they fixed almost bugs in the old version.
The developers are not taking this seriously or I'm missing something? I mean how could they implement SegWit without a making standard for verifying and signing messages? I didn't knew this until saw a couple of Reddit posts about Trezor and Ledger nano S.
There already is a standard: the one that we have been using for the past several years. Messages shouldn't really be "signed with an address" or verify to an address since addresses really correspond to a specific output script whereas signed messages (signed anything really) corresponds to a public key. P2PKH and P2WPKH addresses also happen to correspond to a public key so people found it simpler to abstract "signed with public key" to "signed with a public key that corresponds with this address". P2PKH addresses can easily be translated to a P2WPKH. But message signing and verification really shouldn't have anything to do with addresses, rather it is all about key hashes which P2PKH and P2WPKH both use. 
The developers are not taking this seriously or I'm missing something? I mean how could they implement SegWit without a making standard for verifying and signing messages? I didn't knew this until saw a couple of Reddit posts about Trezor and Ledger nano S.
I actualy feel stupid when I realize how little I know compared to u guys damn ...
I don't know why you didn't include it, but from my point of view is a good idea to include the SHA256SUMS text in this topic, of course, people should always research it for themself but at least they will have one more site to contrast his info.
Code:
b1ac0cd472f98040fbce9cea79348da2c6140a452427f9fe56d060413ec67f2d bitcoin-0.15.0.1-aarch64-linux-gnu.tar.gz
7fb2290464ff056213593878cac1d111422204e81b1ccb93f95b145c309895c5 bitcoin-0.15.0.1-arm-linux-gnueabihf.tar.gz
061bdd552fdc048a98e04ab436165b121346ecd989e1bc91db0246888fcadf7d bitcoin-0.15.0.1-i686-pc-linux-gnu.tar.gz
23a36e28295ef05faf67d41be0610d5f5f1059d904aa74efca7a6700a82d6dc2 bitcoin-0.15.0.1-osx64.tar.gz
9f90a5b5623287b762e3280fd86fc7adc7180a071513d5d663133f030452b1dd bitcoin-0.15.0.1-osx.dmg
b57e9e756018e4082f5557a4216195b0cd197c5a62473b6fe0509a0aa71e519b bitcoin-0.15.0.1.tar.gz
f3e7ef9ac9d510a185efb0f0253dc1f49d627768999a66f13e86de4c38854680 bitcoin-0.15.0.1-win32-setup.exe
49578a464d043f278805b145cd8f59b115e6f41cd56de0a90049da1781df9d59 bitcoin-0.15.0.1-win32.zip
f0aebade2b43e253ad66fd920e00524048f5a9b9933936e735844d316433791a bitcoin-0.15.0.1-win64-setup.exe
25efad99a4128d9f197d7eb1c175e7597478ae39e3d05805f14e9c01392b41ae bitcoin-0.15.0.1-win64.zip
ae3efa47bf87a694a5368cd6fea96c9942fe9be7856720b5027c8902e46a88d1 bitcoin-0.15.0.1-x86_64-linux-gnu.tar.gz
I'm interested, if on old laptops the speed of synchronization will be higher too
Yes. The speedup of 0.15.0 is more noticeable on slower systems, and those that use the default dbcache size.
I'm interested, if on old laptops the speed of synchronization will be higher too
Does anyone know how do I download the original Bitcoin first?
"Original Bitcoin"? This is the *original Bitcoin*.Is there some up and coming changes planned for BitCoin that is going to cause another split???
No. There is a planned altcoin by a malicious group of corporate baboons called Segwit2x.
Is there some up and coming changes planned for BitCoin that is going to cause another split???
Does anyone know how do I download the original Bitcoin first?
A lot of advantage with the new wallet. Day by day the news are better and better. Keep it on and thank for the update.
Great news!! I hope it will get better and better
Excellent news! I will have to get my local wallets updated this weekend!
Finally a wallet that is stable from my point of view! Good job achow
I agree it finally seems like things are working very well even on my old clunky lappy top. 
Finally a wallet that is stable from my point of view! Good job achow
Ah, sorry, was working from (apparently very bad) memory.
So to answer Omega's question, presumably Bech32 addresses will in fact be more difficult to create vanity addresses with?
No, it will about the same difficulty. The bitness for what people will be using as vanity addresses (P2WPKH) is the same. It's still a 160-bit hash that you need to grind in order to generate a vanity address.So to answer Omega's question, presumably Bech32 addresses will in fact be more difficult to create vanity addresses with?
Because of the disallowing of mixed case though, I'd imagine it would be harder actually, because what was once valid like 1AddreSs would not be valid any longer right?
EDIT: hmm no I don't think that's an issue actually because it's base32, don't worry
Ah, sorry, was working from (apparently very bad) memory.
So to answer Omega's question, presumably Bech32 addresses will in fact be more difficult to create vanity addresses with?
No, it will about the same difficulty. The bitness for what people will be using as vanity addresses (P2WPKH) is the same. It's still a 160-bit hash that you need to grind in order to generate a vanity address. So to answer Omega's question, presumably Bech32 addresses will in fact be more difficult to create vanity addresses with?
I think it would, not 100% sure, there may be some mathematical subtleties I'm not aware of. In principle, it should (I think this new Bech32 format is 32-bit in length and using base 36 numbers, whereas the current address format is 33 bit and uses base 58 numbers).
No, that is completely and absolutely wrong.First of all, current addresses are 160 bits in length (bitness is not the same as character length). Bech32 addresses are either 160 bits or 256 bits. Bech32 uses base 32 and it will actually be longer than current addresses.
Ah, sorry, was working from (apparently very bad) memory.
So to answer Omega's question, presumably Bech32 addresses will in fact be more difficult to create vanity addresses with?
Few post up
Oh, I missed that.He's wrong.
I think it would, not 100% sure, there may be some mathematical subtleties I'm not aware of. In principle, it should (I think this new Bech32 format is 32-bit in length and using base 36 numbers, whereas the current address format is 33 bit and uses base 58 numbers).
No, that is completely and absolutely wrong.First of all, current addresses are 160 bits in length (bitness is not the same as character length). Bech32 addresses are either 160 bits or 256 bits. Bech32 uses base 32 and it will actually be longer than current addresses.
Not sure going backwards is the way to go with bitcoin, ie the shorting of address length.. Seeing they want to use a different address for every single transaction. I mean people thought 4 billion ip (which also is 32 bit) addresses would be enough...
What are you talking about? The address length is not becoming shorter.Few post up
Carlton Banks:
Quote "I think it would, not 100% sure, there may be some mathematical subtleties I'm not aware of. In principle, it should (I think this new Bech32 format is 32-bit in length and using base 36 numbers, whereas the current address format is 33 bit and uses base 58 numbers)."
Might had misunderstood .. been known to happen
Jump to: