Bitcoin Forum
April 23, 2017, 08:00:31 PM *
News: Latest stable version of Bitcoin Core: 0.14.1  [Torrent]. (New!)
  Home Help Search Donate Login Register  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 ... 432 »
1  Bitcoin / Technical Support / Re: Core 14.0: unspent output stuck in blockchain (weird) on: Today at 05:45:32 PM
How much time can it take to rescan the entire blockchain nowadays? I haven't done that in ages. My HDD is a 7200 rpm one, I need to buy an SSD because when something like this happens, it's such a waste of time waiting for the thing to end.
Rescanning should only take at most a few hours, usually somewhere in the tens of minutes I think. Rescanning is not the same as redownloading or reindexing.

I will try later.

What part of debut.log you want? it's a 6.5mb file so I guess you only need the recent entries.
As much as possible from the bottom. Preferably including the entries around the time of when you sent the transaction in question.

I've run listunspent and there's a ton of transactions there, it will take me ages to find the address im looking for. They should add a ctrl+f search feature on the console.
Copy and paste the output to a text editor and use the search function there.
2  Bitcoin / Armory / Re: Help with Armory initial setup and online mode on: Today at 05:42:57 PM
I think I need to use the main Bitcoin network. Not really sure, whatever's easiest. I'm trying to get an Armory wallet online to receive funds.
The testnet is for development and testing only and coins there have absolutely no value whatsoever.

You want to use the mainnet. Make sure that when you run Bitcoin Core and Armory that you do not have the -testnet option set anywhere in their startup commands. Make sure that you are using the normal Bitcoin Core shortcut, not the testnet shortcut. The normal shortcut has an orange icon, the testnet one is green.
3  Bitcoin / Armory / Re: Help with Armory initial setup and online mode on: Today at 04:57:10 PM
You are using testnet. Are you trying to do that or are you trying to use the main Bitcoin network?
4  Bitcoin / Technical Support / Re: entropy on: Today at 04:41:55 PM
Am I right that we do only use an entropy if we make a BIP32, BIP38 or BIP41 wallet. And we do not use entropy if we only need a wallet with one single public and private key?
No, you are wrong. Entropy is used in every single operation that involves generating random numbers, and that includes private keys.

If I am not right:
What is the advantage to generate a single private/public key, using an entropy (made by a cube), instead of generate the private/public key directly with a cube and convert the resulting numbers of the cube directly into a "52 characters base58".
Private keys are 256 bit integers, not just a 52 character string in base58. The private key must fall within a certain range and actually using a random number generator and key generating software ensures that the private key is valid.
5  Bitcoin / Technical Support / Re: Stuck transaction and old software on: Today at 03:45:48 PM
I just wanted to check that the solution the OP was to try: install latest Bitcoin Core (now 0.14.1) and then run the "abandon transaction" command to get rid of the phantom transaction and restore the BTC that did not get sent - worked for him.
You don't need to run that command now, just right click the transaction in question and choose the "Abandon transaction" option.

And just to be sure since I haven't upgraded in years - to upgrade to the new Bitcoin Core on my Windows 7 machine I just run the installer downloaded from
Yes. You may need to start Bitcoin Core with -upgradewallet however in order to make sure that everything works.

P.S. I split your question into its own thread. Please do not hijack someone else's thread with your own questions and issues even if you think the problem is the same.
6  Bitcoin / Technical Support / Re: Core 14.0: unspent output stuck in blockchain (weird) on: Today at 03:40:05 PM
What should I do? im scared to screw something up.
How do we get our money back?
Try running a rescan. Start Bitcoin Core with the -rescan option. This will rescan the entire blockchain for all transactions related to your wallet.

Can both of you also please post your debug.log file?

And how do I properly migrate to HD format? I create a new wallet, then generate addresses and send the BTC there with the previous wallet?
7  Bitcoin / Armory / Re: Help with Armory initial setup and online mode on: Today at 03:37:10 PM
Thank you for the reply. I get the following Database error when I open Armory.

Armory failed to spawn the DB!
Continuing operations in offline mode instead.
Refer to the dbLog.txt for more information.
Please post the dbLog.txt file which can be found in the Armory data folder.
8  Bitcoin / Development & Technical Discussion / Re: I hold no view seeking information: 4 to 8 MB now. Technical Objections? on: Today at 01:42:59 AM
That is nonsense.  A Bitcoin fork in the context we are speaking about would be all over the news, maybe even mainstream news.
It's all anyone would talk about for weeks and months.
BU, Segwit, Classic, and XT are all over the news and even hit mainstream media. It has been nearly what everyone has talked about for months, practically years. Just take a look at the first page of Bitcoin Discussion and of both subreddits; BU and segwit (and previously Classic and XT) comprise a significant portion of what people are talking about. And yet a significant number of people still don't know what they are and ask questions about them, just like the OP of this thread. The current situation is comparable to said hypothetical hard fork and yet many people are still asking questions about the proposals and confused about what they are and what they do.

Anyway, I've made point that your objections are solvable.  People that don't want things to be solved will always see objections.
You have in no way addressed my counter points to your "solutions" to my objections.
9  Bitcoin / Development & Technical Discussion / Re: I hold no view seeking information: 4 to 8 MB now. Technical Objections? on: Today at 12:56:01 AM
They could, sure.  But I doubt there would be much confusion about what was happening.
Bitcoin has quite a large userbase, and I'm pretty sure that a significant portion of the community would not really be aware of a hard fork (just like a significant portion of the community doesn't really seem to be aware of BU or segwit or know anything about them). Furthermore, there is an issue of transaction replay, what the new coins are listed as in exchanges, and what they are calling themselves. If both forks are calling themselves "Bitcoin" or some variation of that (e.g. "Bitcoin Original" or something), then that can be confusing. It is also especially confusing for new users who just started using Bitcoin or are about to start using Bitcoin when the fork happens as they don't know enough about what is going on to make an informed decision. Unless a hard fork actually gains consensus (i.e. practically everyone in the community agrees with it), I think there will be confusion when a hard fork happens.
10  Bitcoin / Development & Technical Discussion / Re: I hold no view seeking information: 4 to 8 MB now. Technical Objections? on: Today at 12:44:36 AM
How so?  If the hard fork was done with a clear majority of hashpower (especially via a majority of pools), the longest chain would clearly be Bitcoin.
A hard forks require not just a majority but practically everyone involved. That means it must have nearly all miners and nearly all users. Just a "clear majority" (e.g. 75%) is not enough as the remaining can still keep the original chain going, albeit rather slowly for a few weeks. Even if all of the current hash power forked away, users who did not go along with the fork can also keep the original chain going by using older mining hardware which had been previously retired.
11  Bitcoin / Development & Technical Discussion / Re: I hold no view seeking information: 4 to 8 MB now. Technical Objections? on: April 22, 2017, 09:29:46 PM
Mostly correct, but these problems are solvable. 

Flextrans (bunlded in BitcoinClassic)  offers an already coded solution to the quadratic hashing.   We can also limit the transaction size or number of sigops.
Segwit also offers an already coded, tested, and reviewed (flextrans has not had the same level of testing and review. IIRC the current implementation has many vulnerabilities in it as well) solution to quadratic sighashing. However, changing to flextrans is a lot more work than changing to segwit. It completely rewrites the entire transaction format. Doing a complete rewrite of that in every single wallet software will take a lot of time, and there are a lot of things that can be messed up in rewriting that. As someone who has partially implemented segwit for a wallet, segwit is really not that bad to implement as it is an extension on the existing transaction format.

Limiting the transaction size is not really a solution. It also prevents people from making those large transactions which can, at times, actually be useful. For example they can be used to clean up a large amount of spam UTXOs but cost less than multiple transactions. F2pool did this with the large 1 MB transaction they made when they cleaned up a lot of small, spam UTXOs from broken brainwallets.

Bandwidth and diskspace requirements would increase naturally, but Gavin did testing on 8mb blocks, and if you think about it, even full 32mb blocks only
represent 1.68 TB a year of storage.
As I said, the concern is not just on disk space but also bandwidth.

Do you also realize that people aren't going to be buying new hard drives every year just to store the blockchain? Maintaining a growth of 1.68 TB a year would be quite burdensome on node owners as they would constantly have to get new hard drives and have the bandwidth to allow that much data to and from their node to multiple peers while still also having disk space for their personal data and bandwidth for personal use.

Hard forks require coordination, but many alt coins have successfully hard forked without any major issues that I'm aware of, and I don't think it would require a year. 
Even if it was done very abruptly, miners kicked off the main chain unexpectedly could simply rejoin. 
Altcoins don't have the same number of users, network conditions, market cap, or development situation as Bitcoin does. Bitcoin and altcoins are not comparable.

It is not an issue of "kicked off the main chain" but rather that a short-term, abrupt hard fork would almost certainly result in two chains and a lot of uncertainty about which is Bitcoin.
12  Bitcoin / Technical Support / Re: Core 14.0: unspent output stuck in blockchain (weird) on: April 22, 2017, 09:14:18 PM
The address you won't recognize is called a change address. You won't be able to actually see what your change addresses are as they are handled internally by the wallet and typically never shown to the user. Just because you don't recognize it does not mean that you don't control the address.

To make sure that the address is yours, go to Help > Debug Window and click on the console tab. Then type
validateaddress <address>
where <address> is the address in question. Then hit enter.

In the output, look for the field "ismine". If that is true (will look like "ismine": true,), then the address is yours and is controlled by your wallet.

Double check that your balance is actually what you expect it to be. The transactions list should say that you are sending 3 BTC, not 3.2.
13  Bitcoin / Armory / Re: Help with Armory initial setup and online mode on: April 22, 2017, 09:10:22 PM
0.95.1 has issues with starting it's own bitcoind (Bitcoin Core). You will need to start Bitcoin Core manually.

In Armory, go to File > Settings and uncheck "Let Armory run Bitcoin Core in the background for me". Then stop Armory, start Bitcoin Core, let Core sync, and then start Armory.
14  Bitcoin / Bitcoin Discussion / Bitcoin Core 0.14.1 Released on: April 22, 2017, 01:45:29 PM
Bitcoin Core version 0.14.1 is now available from:

This is a new minor version release, including various bugfixes and performance improvements, as well as updated translations.

Please report bugs using the issue tracker at github:

To receive security and update notifications, please subscribe to:


Bitcoin Core is extensively tested on multiple operating systems using the Linux kernel, macOS 10.8+, and Windows Vista and later.

Microsoft ended support for Windows XP on April 8th, 2014, No attempt is made to prevent installing or running the software on Windows XP, you can still do so at your own risk but be aware that there are known instabilities and issues. Please do not report issues about Windows XP to the issue tracker.

Bitcoin Core should also work on most other Unix-like systems but is not frequently tested on them.

Notable changes
RPC changes
  • The first positional argument of createrawtransaction was renamed from   transactions to inputs.
  • The argument of disconnectnode was renamed from node to address.

These interface changes break compatibility with 0.14.0, when the named arguments functionality, introduced in 0.14.0, is used. Client software using these calls with named arguments needs to be updated.


In previous versions, getblocktemplate required segwit support from downstream clients/miners once the feature activated on the network. In this version, it now supports non-segwit clients even after activation, by removing all segwit transactions from the returned block template. This allows non-segwit miners to continue functioning correctly even after segwit has activated.

Due to the limitations in previous versions, getblocktemplate also recommended non-segwit clients to not signal for the segwit version-bit. Since this is no longer an issue, getblocktemplate now always recommends signalling segwit for all miners. This is safe because ability to enforce the rule is the only required criteria for safe activation, not actually producing segwit-enabled blocks.

UTXO memory accounting

Memory usage for the UTXO cache is being calculated more accurately, so that the configured limit (-dbcache) will be respected when memory usage peaks during cache flushes.  The memory accounting in prior releases is estimated to only account for half the actual peak utilization.

The default -dbcache has also been changed in this release to 450MiB.  Users who currently set -dbcache to a high value (e.g. to keep the UTXO more fully cached in memory) should consider increasing this setting in order to achieve the same cache performance as prior releases.  Users on low-memory systems (such as systems with 1GB or less) should consider specifying a lower value for this parameter.

Additional information relating to running on low-memory systems can be found here:

0.14.1 Change log

Detailed release notes follow. This overview includes changes that affect behavior, not code moves, refactors and string updates. For convenience in locating the code changes and accompanying discussion, both the pull request and git merge commit are mentioned.

RPC and other APIs
  • #10084 142fbb2 Rename first named arg of createrawtransaction (MarcoFalke)
  • #10139 f15268d Remove auth cookie on shutdown (practicalswift)
  • #10146 2fea10a Better error handling for submitblock (rawodb, gmaxwell)
  • #10144 d947afc Prioritisetransaction wasn't always updating ancestor fee (sdaftuar)
  • #10204 3c79602 Rename disconnectnode argument (jnewbery)
Block and transaction handling
  • #10126 0b5e162 Compensate for memory peak at flush time (sipa)
  • #9912 fc3d7db Optimize GetWitnessHash() for non-segwit transactions (sdaftuar)
  • #10133 ab864d3 Clean up calculations of pcoinsTip memory usage (morcos)
P2P protocol and network code
  • #9953/#10013 d2548a4 Fix shutdown hang with >= 8 -addnodes set (TheBlueMatt)
  • #10176 30fa231 net: gracefully handle NodeId wrapping (theuni)
Build system
  • #9973 e9611d1 depends: fix zlib build on osx (theuni)
  • #10060 ddc2dd1 Ensure an item exists on the rpcconsole stack before adding (achow101)
  • #9955/#10006 569596c Don't require segwit in getblocktemplate for segwit signalling or mining (sdaftuar)
  • #9959/#10127 b5c3440 Prevent slowdown in CreateNewBlock on large mempools (sdaftuar)
Tests and QA
  • #10157 55f641c Fix the test (sdaftuar)
  • #10037 4d8e660 Trivial: Fix typo in help getrawtransaction RPC (keystrike)
  • #10120 e4c9a90 util: Work around (virtual) memory exhaustion on 32-bit w/ glibc (laanwj)
  • #10130 ecc5232 bitcoin-tx input verification (awemany, jnewbery)

Thanks to everyone who directly contributed to this release:

  • Alex Morcos
  • Andrew Chow
  • Awemany
  • Cory Fields
  • Gregory Maxwell
  • James Evans
  • John Newbery
  • MarcoFalke
  • Matt Corallo
  • Pieter Wuille
  • practicalswift
  • rawodb
  • Suhas Daftuar
  • Wladimir J. van der Laan

As well as everyone that helped translating on Transifex.
15  Bitcoin / Development & Technical Discussion / Re: I hold no view seeking information: 4 to 8 MB now. Technical Objections? on: April 22, 2017, 03:48:52 AM
There are multiple problems with a block size increase in general, regardless of how big you make it. While 4 or 8 MB might sound reasonable to you, it in fact is not really that sustainable when you consider everything else that can result from having larger blocks.

An important thing to keep in mind when designing large robust systems is that you must always assume that the worst case scenario can and will happen.

Firstly, there is the problem with quadratic sighashing. Increasing the block size to 4 MB means that we would be allowing a theoretical 4 MB transaction which, due to its size, can take a long time to validate. A block was mined a while back that took ~30 seconds to validate since it was just one gigantic 1 MB transaction. Due to quadratic sighashing, a similar 4 MB transaction in a 4 MB block would take 480 seconds to validate since sighashing is quadratic.

Secondly, increasing the block size in general increases the burden on full nodes in terms of bandwidth and disk space. Right now the blockchain is already fairly large and growing at a fairly fast pace. It gains ~1 GB every week or so. Considering the worst case scenario, that would mean that the blockchain would grow at a rate of 4 GB per week. That growth is quite large and hard to sustain. Full nodes need to download that amount of data per week and upload it to multiple peers. That consumes a lot of bandwidth and people will likely stop running full nodes due to the extra cost of that bandwidth. Furthermore, it will become more and more difficult to bring new nodes online since it consumes so much bandwidth and disk space so it is unlikely that people will be starting up new full nodes. Overall, this extra cost is a centralizing pressure and will result in fewer full nodes and an increased burden on those who are currently running full nodes. And larger blocks don't just effect the bandwidth and disk space, they also require more processing power and memory to fully process, so that raises the minimum machine requirements as well.

There was a paper published a year or so ago which analyzed the ability of the network to support certain sized blocks, and I think they concluded that based upon network bandwidth alone, the network might have been able to support 4 MB blocks and still keep most of the full nodes. However they did not consider machine specs and requirements for larger blocks so if you factor those in, the maximum handleable block size is likely smaller.

Lastly, such a change would require a hard fork. Hard forks are hard to coordinate and to get everyone on board and upgrade at the same time. By this time, 2 block size increase hard forks have been attempted, and both have failed. With all of the politics, contention, and toxicity going on right now, I highly doubt that we would be able to get the consensus required to activate such a hard fork. Additionally, planning out, implementing, and testing a safe fork (regardless of hard or soft) takes a long time, so such a fork would not be ready for months, if not a year or more.
16  Bitcoin / Development & Technical Discussion / Re: List of past soft forks and OP codes? on: April 21, 2017, 04:41:53 PM
As a learning exercise, I am writing a full node from scratch.  I am currently writing the transaction validation logic, and I know that there have been numerous soft forks and changes/updates to assign NOP's to something useful, but I want to make sure that I don't use the current OP code definition for a time period when the definition was still a NOP.  Is there a list of soft forks and OP code changes I can reference, or do I just have to research that myself and estimate based on the blockchain history and whatever other info I can find..?
All soft forks were done through the BIP process. Take a look through the BIP list: Anything that has "Consensus (soft fork)" for Layer and "Final" for status is a soft fork which has already activated.

I am also wondering how P2SH was originally implemented.  Obviously OP_HASH160 doesn't include the code for "oh and check if the stack object is a script, and if it is, verify it".  Did the "OP_HASH160 <hash> OP_EQUAL" output just automatically require checking redeem scripts when it was implemented?
When BIP 16 activated, it created a new standard output type of the form OP_HASH160 [20-byte-hash-value] OP_EQUAL. Any output of that form is considered a P2SH output. Any P2SH output will always have the last item in the stack after the scriptsig eval (i.e. after the redeemscript was pushed to the stack) evaluated as a script even if it is not a script.
17  Bitcoin / Development & Technical Discussion / Re: Segwit2MB vs ? on: April 20, 2017, 09:21:23 PM
I guess Luke likes to shock others, he himself couldn't seriously expect such proposal to be accepted. Nowhere in the agreement it is stated when actual blocksize increase must happen. He exploited this uncertainty to pervert the meaning just for lulz. If we are playing such games, soon we will need teams of lawyers and our agreements will become tens of pages in thickness.
He did not just "exploited this uncertainty to pervert the meaning just for lulz". If you have read any of what Luke-Jr has said about block sizes and capacity, he genuinely believes that the block size is currently too large because it is difficult to start running a new full node. It is also becoming unsustainable to continue to run a full node since it costs so much in bandwidth, processing power, RAM, and disk space. It wasn't proposed "just for lulz" or to troll anyone but rather because Luke-Jr genuinely thinks that decreasing the block size would help Bitcoin by allowing more people to run full nodes.

On the other hand Sergio's proposal follows the spirit of the agreement. It is simple, honest, it gives each side what they want.
It does not give both sides what they want. Many who support segwit clearly don't support the proposal. A lot of that is because they think that having a 2 MB base block size is too large (that means that witness block sizes can go up to 8 MB). Furthermore, that still allows a 2 MB legacy transaction which takes a long time to validate due to the quadratic sighashing issue. Additionally, since it is a hard fork, there are a number of other things that should be included into it as we don't want to have multiple hard forks but rather one with everything that we want that needs hard forking. Segwit2MB does not address that.
18  Bitcoin / Development & Technical Discussion / Re: Segwit2MB vs ? on: April 20, 2017, 07:17:50 PM
What proposal are you talking about? The one which proposes to shrink blocks to ~300kB or to keep them at 1MB for 7 years?
Yes, that one. It does more than that as it actually grows on a fixed schedule.

OK, I understand, core devs are numerous. It's nearly impossible even to gather all of them in one meeing. So how one could negotiate with them? Saying that they were not represented at the meeting is an excuse for doing nothing. I'd say that there were enough influential, prominent devs there to properly represent their party and make the agreement meaningful.
No. The Core devs at that meeting did not represent Core. As I understand it, they made it very clear at the meeting that they only represent themselves as contributors, not representatives of the project itself.  Furthermore the only statement binding them to do something hard fork related is
The Bitcoin Core contributors present at the Bitcoin Roundtable will have an implementation of such a hard-fork available as a recommendation to Bitcoin Core within three months after the release of SegWit.
Notice how it does not say that the Bitcoin Core project will adopt said proposal, only that the contributors present will make such a proposal which they can recommend to Core.

But currently he's apparently the only one among segwit supporters who tries to resolve the conflict in conformity with the agreement.
His proposal is not in conformity with the agreement. It came way past the deadline (luke-jr's came before the 3 month deadline), he was not at the meeting so his proposal does not count, and his proposal is not recommended by the Bitcoin Core contributors present at the meeting.

Anyways, the Hong Kong agreement is really not in effect and not binding anyways so this is pointless to argue. Technically all parties upheld their parts of the agreement due to the vagueness and loose wording of it.
19  Bitcoin / Technical Support / Re: Transaction fee ? on: April 20, 2017, 06:03:18 PM
The transaction fee is dependent on the size in bytes of the transaction, not the actual amount being transacted. We need to know what the transaction ID of your transaction is to actually know what is wrong with it.
20  Bitcoin / Development & Technical Discussion / Re: Segwit2MB vs ? on: April 20, 2017, 05:59:28 PM
I'm not surprised. So it looks like Segwit2MB is the only proposal up to now, fulfilling the Hong Kong agreement from devs side.
Actually it is not. Luke-jr's proposals are actually the ones that fullfil that aspect of the agreement. Firstly, the group "core devs" did not agree to anything, nor were they represented at that meeting. Rather a couple people who frequently contribute to Core (including luke-jr) were there and those people agreed to propose a hard for proposal which they could recommend. But that does not mean that that proposal would be implemented or accepted by the rest of the Core devs. Luke-jr fulfilled that part of the agreement; he made a hard fork proposal which he could recommend to Core, but the rest of the Core devs did not really like it, so it was dropped.

IIRC Sergio has never contributed to Core not was he at the Hong Kong meeting.
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 ... 432 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!