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.

What is the application? Can you give us a link to where you found it?

I highly suggest that you be very very careful with this. If you cannot find it listed anywhere on this forum, I highly suggest that you delete the app immediately and scan your computer for viruses. Many viruses will masquerade as Bitcoin mining software in order to steal the private keys for your Bitcoin or passwords to any Bitcoin wallets.

But then how do you know that a transaction in a block was actually relayed beforehand? There is no universal mempool, the mempool varies from node to node. Furthermore, you are assuming that every node has a mempool, but people can run nodes that are blocks only. They would not be able to validate a block under this rule. You are also assuming that all nodes will keep all transactions and receive them at roughly the same time. However you cannot assume that. Many nodes will evict transactions or not accept them if they violate local node policy (which does not have to match the node policies of anyone else). For example, there could be a race condition where a bunch of low fee transactions are evicted just before a block is received by the node so this evicted transactions are no longer in the mempool and the block considered invalid. Furthermore, a newly started node will fail to properly sync because it would consider all blocks invalid (after all, it still has to validate consensus rules) because it has none of the transactions in those blocks in its mempool. A block that is found very shortly after a node starts up would also be rejected as that node's mempool has not filled up with transactions yet.

Suppose the miner who found A is super lucky, and found B, then C very quickly. Now all miners will be using the chain including the invalid block, and that invalid block could be maliciously crafted to create transactions which allows the miner who found the block to spend the Bitcoin.

You are also assuming that all miners are fully validating every single block before they build on top of it. Unfortunately, we know for a fact that this is absolutely not the case. Many miners are SPV mining; they will begin mining on top of a block before it is fully validated. With SPV mining, it is very possible that miners will end up mining on top of an invalid block and thus extending the chain for that block and find enough blocks so that its is valid.

That does nothing to help with figuring out what transactions are in nodes' mempools. Standardness  rules are not consensus rules, they are local node policy rules. Anyone can change their local node policy. Even so, there are transactions which are standard, but still rejected by other node policies. Relying on standardness rules is not enough to say that you know what transactions are in everyone's mempools.

The miners are then redefining the consensus rules still. They can do so every 3 blocks; every 3 blocks can basically have whatever consensus rules it wants then so long as everyone mines a block on top of the invalid one, which is entirely possible given that many miners do SPV mining.

But miners shouldn't have full and absolute power over everything. Full nodes prevent miners from changing the consensus rules willy-nilly. They provide an incentive for miners to not produce invalid blocks. With your proposal, they now have an incentive to produce invalid blocks because in that invalid block they can make a ton of money and have a fairly high likelihood of making that invalid block a valid accepted block.

No. This is a horrible idea. It gives miners absolute control over the consensus rules. The consensus rules will stop being consensus rules and suddenly become Miners Want This Rules. Making such a drastic change will allow miners to change whatever rules whenever they want. That is completely antithetical to Bitcoin and completely defeats the purpose of full nodes. The point of running a full node is to ensure that miners follow the consensus rules, not just to have the entire blockchain. Your proposal completely removes that check on miners' power.

By your proposal, miners could decide that they can make a transaction which spends all of the Bitcoin back to themselves, put it in a block, and make a ton of money. Or miners can remove the block subsidy schedule and just make as much Bitcoin as they want out of thin air, and everyone will follow. This idea is just plain stupid and simply hands over all control of Bitcoin to the miners, instead of splitting it between users and miners.

They only appear when you are logged in.

Forum time is UTC.

Not just ETH, look more carefully at everyone's badges 

The blockchain is ~110 GB now. Bitcoin Core will build its own databases (Bitcoin Core is the full node behind Armory) and Armory also has its own databases. In total, there will be an additional ~5 GB of databases with the blockchain.

Yes, you will need to download the entire blockchain. Armory and Bitcoin Core are full node wallets, they require the entire blockchain. This provides the best security and privacy. SPV wallets like Electrum severely risk your privacy, and potentially the security of your Bitcoin.

Yes. Anyone can rebroadcast a transaction. You can get the raw hex of the transaction by appending ?format=hex to the blockchain.info URL for the transaction. Then copy and paste the raw transaction to a broadcast utility like https://blockchain.info/pushtx

Binaries are not committed to the source code, they are not source code. You can can get the 0.96 testing binaries from https://github.com/goatpig/BitcoinArmory/releases/tag/v0.95.99.1-testing

Your transaction spends from an unconfirmed transaction, which spends from another unconfirmed transaction, and so on and so forth until this transaction: https://blockchain.info/tx/7a39996d855d0db95b886a6d4bd2a855e5fe7ded0fb888ddb21a7a7a185e4b0b.

Your transaction cannot confirm until all of the unconfirmed transaction it depends on confirm as well. As for why this transaction at the top of the unconfirmed chain has not confirmed yet, it probably has to do with poor propagation as I cannot find it on other block explorers or on my own node. To make it confirm faster, you will need to remind the network of all of the unconfirmed transactions in the chain by rebroadcasting the transactions.

The segwit address type is the p2sh nested segwit addresses.

Yes. AFAICT this is an issue with all platforms, not just with one OS.

Over the long term, there will be more on chain transactions and more costs with your scenario.

In the US, the average car is ~$25,000 and the median household income is ~$50,000 per year.

Under your scenario:
Alice opens the channel with the Car dealership (1 on chain tx). In order for her employer to pay Alice through the car dealer, they would need to have a payment channel with more than $50,000 to pay Alice for the year (which I find unlikely), or they will need to load their payment channel to match Alice's salary (another on chain tx). Now in order for Alice to receive her entire $50,000 salary, she (or the car dealer) will need to close a payment channel (another on chain tx), load up Alice's channel (another on chain tx), and probably open up another channel with whoever they closed with (another on chain tx) In one year, Alice will have made or required to be made 5 on chain txs. Furthermore, the car dealer is likely to charge a fee for being a third party between Alice and the employer.

Under my scenario:
Alice sends 1 on chain transaction for the car. She opens a payment channel with her employer, who loads into the channel however much they expect to pay her that year, so $50,000 (another on chain transaction). At the end of the year, the channel is loaded with her next year's salary (another on chain transaction). In total, she makes only 3 on chain transactions, and does not need to pay a third party for being a hub. Like with the Car dealer, Alice can buy things by using her employer as a hub, but because the channel already has her entire yearly salary there, no on chain txs need to be made to load any more money into that channel (unless she is spending from here savings).


Lightning is fairly useless for big one time purchases. It is far more efficient to use just a normal on chain transaction to make a big purchase like a car or a house.

A far more likely scenario for one party to put in 0 funds into a channel is for an employer to be paying an employee.

For Segwit, read the BIPs: 141, 143, and 144.

For BU, read BUIP 1

You will need to reindex the blockchain. Start Bitcoin Core with the -reindex option. Note that this is a command line option for when you start Bitcoin Core, NOT something you enter into Core's debug console. For specific instructions on how to start Core with -reindex, we need to know what OS you are using.

As much as possible, although you can really omit anything that is like "log file opened ... armorycpplog.txt" as that log file is no longer used.