Hi goatpig. I know 0.96 will be released when it is ready  Do yo have an estimated date? I know you wouldn't like to commit to a shipping date or so. I just ask this to know how the roadmap is going through. Thanks for your support and efforts for the community! :-) The first testing build should be out today. Goatpig just bumped the version numbers and yesterday he told me he was going to release the first testing binaries today. |
|
|
|
|
Downgrade to Bitcoin Core 0.13.2 for now. The issue causing this has been fixed in 0.96 which will be released soon.
|
|
|
|
Will SegWit be mandatory deployed since Aug. 1? I've read from a post from a Chinese forum that in BIP 148: https://github.com/bitcoin/bips/blob/master/bip-0148.mediawikithe "mandatory" start time of originally suggested Oct. 1 was predated to Aug. 1. Although the proposal is written "soft fork", when no concensus is made till Aug. 1, will a hard fork suddenly occur at that time? So my questions: What is actually written in this code, and is this BIP accepted and will be released in the new Core version? BIP 148 (aka UASF) is not accepted by pretty much all developers. It has not been accepted by Core nor is it likely to be accepted and implemented by Core. As of now, the segwit implementation in Core is as is specified in the segwit BIPs, which do not include BIP 148. |
|
|
|
starts with a 6 from bitaddress. does the encryption have anything to do with it?
Yes. That means that it is BIP 38 encrypted. Bitcoin Core does not support importing BIP 38 encrypted private keys. You will need to decrypt it and get the normal WIF private key. |
|
|
|
|
Are you sure you copied it correctly? Are you sure your private key is in WIF format (begins with 5, K, or L)?
|
|
|
|
|
No. In the case of a hard fork, there will be one block that causes the fork. This block is one that is invalid on the original chain but valid on the new chain, and is the first new block of the new chain. Because each block is related to the block before it, and that is related to the block before it, and so on and so forth, a block in the new chain that would otherwise be valid on the original chain will still be invalid on the original chain due to it having an invalid ancestor.
|
|
|
|
I cannot access the post (thread) by your link. It seems that it got deleted already. Do you have a snapshot or could you tell us what was in that post that made you think that someone is actually looking for something bad?
It seems it has been trashcanned (I can still see it) and his other post (a duplicate) has been deleted. Is this what you consider as evil?
No, but because someone has access to his account and is fairly up to date on Bitcoin happenings, so it is possible that someone could use his account to post opinions and then later citing the posts as sources in support of or against someone/something. Hal is after all a fairly well known figure in Bitcoin and people tend not to check sources or may not know that he has died.
Edit: Theymos has locked the account: https://bitcointalk.org/index.php?topic=1847311.msg18382142#msg18382142I kept his account unlocked because I thought his family members might want to look at his PMs or something, but this is looking like his account was almost certainly compromised. So I locked his account.
The person who controls his account gained access via email-password-reset, so his email is probably also compromised.
|
|
|
|
|
There is currently an issue with 0.95.1 and 0.14.0. The issues have been resolved for 0.96, which will be released soon.
|
|
|
|
So I had a think about this (for 5 minutes  ) and I see that even I may have been over stating the quadratic issue? Are you basically implying that the quadratic issue is caused by the number of inputs/outputs? or is it also how the transaction is created and the number doesn't really matter too much? Would it be correct to say that a transaction size limit would solve the quadratic issue? i.e. pick a number 50K? 25K? limit per transaction and then it doesn't really matter? Clearly if the block size ever did get to 32MB, it would be foolhardy to allow ~32MB transactions, so there should be some limit in there somewhere anyway. Putting a limit on the transaction size doesn't really solve the issue. Sighashing will still be quadratic. The only way to actually fix that is to make it not quadratic anymore. Putting a limit on transaction size still means that the biggest transaction can still potentially take a long time to validate, especially on lower end hardware. But then, what is a good limit to put on transactions? Are we going to be bickering over the transaction size limit like we are over the block size limit? (I think it is very likely that is going to happen). How would you measure what a good limit is? FWIW, I think Bitcoin XT and Classic put a limit on the transaction size as their fix for the quadratic sighashing issue. ... and spent another 5 minutes and I now think achow101 is leading me astray  My point about the hash is that when bitcoin receives a transaction, the inputs and outputs and the transaction hash are fixed. ... ignoring malleability, since that really doesn't matter in this case, since it can be treated as another transaction, which just happens to have the same inputs and outputs ... so anyway, as a miner, if it takes a long time to process a block, it's far from ideal, but if bitcoin has stored that information about all the transactions it has in it's mempool (or some or most or ... whatever) then when a block comes in, it will ONLY need to verify transactions in the block that have a txn hash it doesn't already know (or hasn't stored the processed information). Yes. And that is what stuff like compact blocks and xthin does (among many other things). Thus in this case, the quadratic issue is a complete non-event, unless we've never seen the transaction hash before.
Yes, and that is the main concern. The concern is not that people are going to make big transactions and broadcast them to the network. Rather it is that some miner is going to make a big transaction (like f2pool did a while ago) and include it in their own block without broadcasting it to everyone else beforehand. |
|
|
|
Every couple of hours, ArmoryDB disconnects and reconnects to my Bitcoin Core node for some reason. It hits a StopBlockingLoop exception in processDataStackThread but I am not sure why. I am running a build of Bitcoin Core's development branch, so it may be possible that something was changed for the next version of Core that is causing this error to occur. If that is the case, then this needs to be fixed so that we don't get a repeat of the "transaction timed out" errors. I put it in gdb and let it run until that exception was thrown. Here is the backtrace of when gdb stopped at the exception being thrown (I think this is the right place for it to stop): #0 0x00007ffff78c58bd in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1 0x00000000005db046 in BlockingStack<std::vector<unsigned char, std::allocator<unsigned char> > >::terminate (
this=0x7fff9c000930, exceptptr=...) at ThreadSafeClasses.h:894
#2 0x00000000005d0891 in BitcoinP2P::<lambda(std::vector<unsigned char, std::allocator<unsigned char> >, std::__exception_ptr::exception_ptr)>::operator()(std::vector<unsigned char, std::allocator<unsigned char> >, std::__exception_ptr::exception_ptr) const (__closure=0x7fff980008c0, socketdata=std::vector of length 0, capacity 0, ePtr=...)
at BitcoinP2P.cpp:995
#3 0x00000000005d3a4a in std::_Function_handler<bool(std::vector<unsigned char, std::allocator<unsigned char> >, std::__exception_ptr::exception_ptr), BitcoinP2P::pollSocketThread()::<lambda(std::vector<unsigned char, std::allocator<unsigned char> >, std::__exception_ptr::exception_ptr)> >::_M_invoke(const std::_Any_data &, <unknown type in /home/andy/bitcoin/BitcoinArmory/ArmoryDB, CU 0xa74053, DIE 0xaecb9d>, <unknown type in /home/andy/bitcoin/BitcoinArmory/ArmoryDB, CU 0xa74053, DIE 0xaecba2>) (__functor=...,
__args#0=<unknown type in /home/andy/bitcoin/BitcoinArmory/ArmoryDB, CU 0xa74053, DIE 0xaecb9d>,
__args#1=<unknown type in /home/andy/bitcoin/BitcoinArmory/ArmoryDB, CU 0xa74053, DIE 0xaecba2>)
at /usr/include/c++/5/functional:1857
#4 0x0000000000626085 in std::function<bool (std::vector<unsigned char, std::allocator<unsigned char> >, std::__exception_ptr::exception_ptr)>::operator()(std::vector<unsigned char, std::allocator<unsigned char> >, std::__exception_ptr::exception_ptr) const (this=0x7fffa3ffee30, __args#0=std::vector of length 0, capacity 0, __args#1=...)
at /usr/include/c++/5/functional:2267
#5 0x000000000061fd72 in BinarySocket::readFromSocketThread(int, std::function<bool (std::vector<unsigned char, std::allocator<unsigned char> >, std::__exception_ptr::exception_ptr)>) (this=0xbb77d0, sockfd=2147483647,
callback=...) at SocketObject.cpp:378
#6 0x000000000061f301 in BinarySocket::<lambda()>::operator()(void) const (__closure=0x7fff9c000b58)
at SocketObject.cpp:216
#7 0x0000000000625958 in std::_Bind_simple<BinarySocket::readFromSocket(SOCKET, ReadCallback)::<lambda()>()>::_M_invoke<>(std::_Index_tuple<>) (this=0x7fff9c000b58) at /usr/include/c++/5/functional:1531
#8 0x00000000006255f6 in std::_Bind_simple<BinarySocket::readFromSocket(SOCKET, ReadCallback)::<lambda()>()>::operator()(void) (this=0x7fff9c000b58) at /usr/include/c++/5/functional:1520
#9 0x000000000062547a in std::thread::_Impl<std::_Bind_simple<BinarySocket::readFromSocket(SOCKET, ReadCallback)::<lambda()>()> >::_M_run(void) (this=0x7fff9c000b40) at /usr/include/c++/5/thread:115
#10 0x00007ffff78f0c80 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#11 0x00007ffff7bc16ba in start_thread (arg=0x7fffa3fff700) at pthread_create.c:333
#12 0x00007ffff705682d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
|
|
|
|
I think it is very interstning that satoshi has some code in there not being active.
No. That is not at all what this thread is about. Satoshi came up with an idea in the whitepaper, but his idea specifically was never implemented. So to sum this up: the diskspace is currently not checked on the core github source? Or did i understand it wrong?
Again, you are completely missing the point of this thread. This thread has nothing to do with Core checking disk space but rather whether a specific feature is implemented in Core. Anyways, Core does tell you if you are running out of space to store the blockchain. However it cannot tell you whether you have enough disk space because that would imply it knows the actual size of the blockchain, and the only way to do that is by downloading the whole thing. |
|
|
|
Update: 0.96.0 has been released. Update to that if you are still experiencing this problem.
Many of you may have noticed that with the Armory 0.95.1 and Bitcoin Core 0.14.0, Armory tends to fail to broadcast transactions and give the "Transaction timed out" and "Transaction broadcast failed" error messages. The underlying issue that is causing this problem has been fixed for Armory 0.96, which will be released soon. However, in the meantime, downgrading to Bitcoin Core 0.13.2 will fix the issue. Once 0.96 is released, you will be able to use Bitcoin Core 0.14.0 again. To downgrade to Bitcoin Core 0.13.2, just download the Bitcoin Core 0.13.2 binaries from https://bitcoin.org/bin/bitcoin-core-0.13.2/ and install them as you would normally install a new version of Bitcoin Core. There is no need to redownload the blockchain nor reindex Bitcoin Core's databases nor rebuild Armory's databases.
Now for the technical details about the problem, for those of you who care. I first noticed this issue back in December, but only very recently have I nailed down why this problem cropped up in the first place. Bitcoin Core 0.14.0 merged a change back in December which changed how Bitcoin P2P messages were being broadcast. Previously, the p2p message header and the message payload were sent all at the same time using the same kernel call. However, during their net refactor and cleanup, this mechanism was changed to send the message header in one call, and then the payload in a separate call. This is more robust and allows for better code separation, but it also causes problems for Armory. The implementation in Armory 0.95.1 for receiving the p2p messages is not able to handle that the two parts of a p2p message are essentially sent separately. It interprets the message header as one p2p message, and the message payload as another p2p message. This means that it is incorrectly parsing the messages. The crux of the issue is that every so often Armory will receive a ping message from Bitcoin Core. However the payload of the ping message is only 8 bytes, but the message header must be 24 bytes. When Armory interprets the ping payload as a separate message, it will throw an exception because it thinks the message is too short. This exception causes the data processing thread to exit and disconnect from Bitcoin Core. Once it disconnects, it will typically reconnect, but the reconnect does not always mean that it will actually be receiving new blocks and transactions and actually remaining up-to-date with the blockchain. Thus, because of this disconnect, when you go to send some Bitcoin, it will fail to either connect to Bitcoin Core or the reconnected connection is messed up and the transaction broadcast times out or just fails entirely. |
|
|
|
Thanks, that is the case.
It means that I will have to reload all the block chain again??
It took a long time.
No. Changing the software version typically does not require redownloading the entire blockchain. Only between some software versions is that required, but not with 0.14.0 to 0.13.2. |
|
|
|
|
No, that is not how Bitcoin works.
Miners mine blocks by changing various fields in the 80 byte block header in order to find one that hashes with SHA256d to a value less than the target. The block itself consists of the block header and then transactions. When miners mine a block, they include transactions in the block and one special transaction called the coinbase transaction. The coinbase transaction is where newly generated Bitcoin come from. They are essentially created out of thin air, not hidden somewhere to be discovered. Miners claim the reward by sending the block subsidy (currently 12.5 BTC) plus all of the transaction fees of the transactions in the block to whatever addresses they want in the outputs of the coinbase transaction.
|
|
|
|
|
Are you using Bitcoin Core 0.14.0? If so, downgrade to Bitcoin Core 0.13.2.
The issue has been fixed in 0.96 which will be released soon. Once it is released, you can go back to using 0.14.0.
|
|
|
|
|
Show Posts
