There is no "restart Bitcoin application" button. There is a button for "Reset options" which will, as you can imagine, reset all of the options to their default settings. That means that you are not using a SOCKS proxy. The "welcome to Bitcoin Core" dialog will appear because that is where you set the datadir, and in the past, the reset options button would set the datadir to the default without notifying the user which caused a lot of confusion. Just set the datadir to wherever you had it set to before and it will use whatever is in there already, such as your wallet, the blockchain already downloaded, and the databases already built for that.

As has been stated multiple times throughout the thread and in an edit to the OP itself, the "post quality" is not being shown because it is highly inaccurate and has been previously used by people as justification for their poor post quality.

With the current lightning spec document, both parties need to put in some amount of money so that both parties have something to lose so there is an incentive for both parties to not scam the other person.

Edit: You can open a channel where only one party funds it. I read this part of the spec incorrectly. See https://bitcointalk.org/index.php?topic=1848861.msg18444685#msg18444685

Go to the Armory data directory (by default it is in %appdata/Armory on windows) and delete the folder named databases then start Armory.

You need to run Bitcoin Core and Armory separately. In Armory's settings, uncheck the box "Let Armory run Bitcoin Core in the background". Then stop Armory, start Bitcoin Core, and restart Armory.

No, it will not have to download the blockchain again. It will use what is already downloaded.

I'll see if I can replicate the issue.

For now, you can use 0.95.1 and downgrade to Bitcoin Core 0.13.2.

Here is a copy of what I have in my lang folder: https://drive.google.com/open?id=0Bxw3ip9QfNOUTU1laEEyU2l6a1E. Extract the zip file into wherever you installed Armory. Make sure that if you double click the lang folder, you see a bunch of files with a .qm extension on them.

The reason the lang folder is not there is due to improper packaging of the binaries and the installer. I have it because I do development of Armory and run straight from source.

That's probably the issue then as it is expecting the translation files to be there. There's probably a packaging problem for Windows.

This topic has been moved to Trashcan.

https://bitcointalk.org/index.php?topic=1852483.0

Duplicate

Even if they are connected to a node that relays all "desireable" transactions, that does not necessarily mean that the node will have all of those transactions stored somewhere in order to properly validate a block. It needs to be able to lookup that a transaction was in its mempool for at least X seconds, and if it doesn't have a mempool, then this is impossible.

A blocksonly wallet still receives transactions when they come in a block, i.e. the transactions have confirmed. You are reducing the security of people running blocksonly nodes as they are trusting that blocks that they receive are valid with regards to the transactions inside of them being in the mempool at least X seconds.

No, bypassing the rule for some time after the proposal deploys is not going to help at all. New nodes don't just come online after a proposal activates; nodes are being restarted all the time and this rule will force a node which just started to reject the blocks because it doesn't have a populated mempool to begin with.

A node can most certainly receive a block before transactions are received. There is no stipulation that blocks cannot be sent before transactions (it's asynchronous). A newly started node with NO MEMPOOL is not likely to receive the transactions that are included in a block if the block is found shortly after the node starts up. Furthermore, new nodes don't populate their mempools with the transactions in the mempool's of other nodes. Nodes only relay a transaction once, right after they receive and validate it.

Even so, it is an attack that is entirely possible and potentially has huge payout.

No, you don't seem to grasp the idea that ALLOWING INVALID BLOCKS MEANS THAT MALICIOUS THINGS CAN BE DONE. Your proposal allows the absolute worst possible thing that can happen in Bitcoin, allowing an invalid block become completely valid. By allowing invalid blocks, you are allowing blocks completely circumvent the consensus rules. What part of that do you not understand? Do you not understand that invalid blocks include more than just being larger than the block size limit?

---

Not necessarily. As I mentioned earlier, an invalid block can be invalid in many ways. It is possible that a miner could make an invalid block which has a massive payout, such as changing the block subsidy to 1250000000000 BTC for that block. Even though the consensus rule is that coinbases need to have 100+ confirmations before they can be spent, this is an invalid block, so consensus rules go out the window. They can make a block which has that huge reward and make and include a transaction which spends that reward to an exchange address thus once they get their invalid block considered valid, they can cash out and make a ton of money to recover their costs.

Has OP stipulated that his "temporarily invalid" block thing is only applicable to certain consensus rules? He has not mentioned that explicitly thus far in this conversation, and it was not mentioned in the OP when I first responded to it.

But waiting for the EC clause to take effect takes time, and this case is a usability issue. Suppose you received a transaction, and that transaction is included in a block. But you perceive that block as invalid because some other transaction in that block was received less than 15 seconds before you received the block, so you mark it as invalid. This is can make Bitcoin less easy to use as some users won't know that their transaction has actually confirmed since the wallet considers the block it was confirmed in to be invalid until ~30 minutes after the confirmation. In fact, a miner could perpetually prevent the EC clause from taking effect for a specific node by always broadcasting an old transaction (i.e. one that was discarded by being older than 1 hour, as was mentioned previously) shortly before broadcasting the block including it. You could do this an effectively take nodes offline for a while.

Run Armory and Bitcoin Core separately. First start Bitcoin Core. Then start Armory. In Armory's settings uncheck the box "Let Armory run bitcoin core in the background" and then restart Armory.

If you go to the folder where you installed Armory, do you see a folder named "lang"?

Goatpig forgot to update the clock on his offline signer.

These paths don't like having spaces in the path. You can remove the space in the path to your installation (which I recommend, many things don't like having spaces in paths) or surround the path you enter with double quotes (")

You don't need to enter any amount when requesting an address. It is entirely optional. There is no limit on how much an address can receive or how many times it can be used. Your wallet will still track the address's balance even if it has received more than the amount requested (which can be whatever you want it to be) and even if you keep reusing the address.

Your proposal requires that all nodes receive and store transactions in order to verify that a block contains "desireable" transactions. Yet blocksonly nodes do not receive and store transactions, thus they cannot receive, verify, and relay blocks.

Even if you don't call blocksonly nodes full nodes, you are still preventing people who want to have the security of a full node (and they are still getting that with a blocksonly node) but don't have enough bandwidth for a normal full node from being able to use their wallets.

Then you run into other issues like people paying too low of a transaction fee and thus getting their transaction evicted after the hour is up.

What if a transaction was in a miner's mempool for over 15 seconds but not in a node's mempool for 15 seconds (due to latency)? What if I just restarted my node (so it's mempool is now empty) and then I receive a block? Do I reject it? I don't have any of the transactions in the block in my mempool. This time rule assumes that mempools will be in sync with each other, and they simply are not.

I know you are going to say "miners will adjust their delay" but miners can't just "adjust their delay" to accommodate every node. Again, what if a new node just started up (which miners won't know about anyways) and has no transactions in its mempool? How do you handle that?

Again, SPV miners cause an issue here, and malicious miners. SPV miners don't verify blocks before they begin building upon them. Given that a majority of the hashrate does this (because mining pools) combined with the malicious miner, they could, with some luck, find the 3 blocks necessary in order to make this invalid block accepted. The blocks would be found before the SPV miners have finished verifying that the invalid block is in fact invalid, and once the three blocks are found, that invalid block is now valid. That is how it would happen.

SPV mining is also called validationless mining. SPV miners are building blocks on top of blocks which they have not yet verified to be valid. This is a problem because you can end up with a situation where SPV miners have extended a blockchain on top of the invalid block enough so that the invalid block would be considered valid under your proposal. SPV miners currently consist of a majority of the hashrate, and having SPV miners extend on an invalid block has happened in the past.

There are no transactions to this address. Are you sure this is correct? Are you able to have the sender rebroadcast the transactions? It is likely that they have been forgotten by nearly all nodes over the course of the week. Can you please also post the transaction ids of your transactions, not just the addresses involved.

If you want to legitimately mine Bitcoin, you will need very special hardware called ASICs. You will make basically 0 money from trying to CPU or GPU mine, which is what this software appears to be doing. Furthermore, there are far better mining software that exist that have more functionality and are probably more efficient but just don't have a GUI. If you actually want to mine Bitcoin, I suggest that you research ASICs and learn how to use the command line in order to run actual mining software.

Yes they are. A full node is a node which fully validates every single block and transaction that it receives. Blocksonly nodes are still full nodes, they fully validate every single block and transaction it receives. In fact, as an outside observer, you would absolutely not be able to tell whether someone is in blocksonly mode or not. There is no indication that they are not just a regular node.

Many people run blocksonly nodes because it significantly reduces the bandwidth requirements for running a full node. You would completely make it impossible for people to run full nodes in a low bandwidth mode such as blocksonly. This is not something that we want to do as some people may not have the resources to run a non-blocksonly full node but also want the security and privacy afforded by a full node.

How do you enforce that? How do you prevent someone from making a ton of super low fee transactions just to spam up mempools and take up more memory, at some point causing nodes to crash? If you require every single transaction to be kept, then you open up an entirely new attack vector.

What the hell does that mean? As you described it earlier, the "delay parameter" is a consensus rule. You can't just "adjust a consensus rule" as you are proposing without causing invalid blocks.

How do you enforce that? minTxRelayFee will still be part of node policy. How do you enforce that the minTxRelayFee is no higher than 20 sat/byte. Furthermore, suppose someone were to spam up the mempool with transactions that are 20 sat/byte so much that nodes crash because the mempools are too big. Now what? Additionally, Bitcoin Core currently implements a floating minTxRelayFee because it prevents such crashes. It limits the mempool to a certain size and bumps up the minrelayfee as it gets fuller.

Suppose Miner A was malicious and got lucky. They made a block which instead of awarding them 12.5 BTC as the subsidy, awarded them 125000000000 BTC as the subsidy. Now what? Everyone is just going to follow along that chain and let that miner have the 125000000000 BTC because he just got lucky and other miners were SPV mining?

I'm not talking about spam. I'm talking about a miner who awards themselves a massive amount of Bitcoin in the block subsidy. Or creates a bunch of transactions which spends UTXOs that they normally are not allowed to spend thus stealing coins.

With SPV mining, a 51% attack is not necessary. Forks have happened before where SPV miners (which consist of >51% of the network as most large pools do this) have mined on top of invalid blocks and in fact made that chain longer than the valid chain until the pool operators intervened and switched the pool back to the valid chain.

The block size limit is a consensus rule. A standardness rule applies to transactions, and is defined by the IsStandard function in the Bitcoin Core source code. That standardness rules are not the same as consensus rules is not just something I think, but is by definition a local node policy, as defined by the reference implementation. There is no such thing as a standard block, only that there are non-standard transactions, which can still be valid and will be accepted by all full nodes if included in a block.

How would you know? How would you enforce this? Local node policies (including standardness rules) are not broadcast among nodes and even if they were, can be easily faked.

As I said earlier, standardness rules are not the same as consensus rules.

Regardless of what type of fork this is, SPV mining will still happen and is still a problem. Those two are completely unrelated things.

No, the worst possible thing that could happen is the acceptance of a completely invalid block. Except under your proposal, such an invalid block can and will be accepted.