Oh, since you are coming from Armory, this is going to be slightly painful.

Segwit only allows compressed public keys, but Armory only uses uncompressed public keys. In order to use Segwit, Armory will compress the keys on-the-fly, but the export will still give you the uncompressed version.

Go to https://github.com/pointbiz/bitaddress.org and download the git repo. That is the source code for bitaddress.org which is a website that is reasonable trusted to not steal your private keys. By downloading the source code, you can access the website locally and thus not send any private keys to a website. Even so, once you finish doing this, you should move your coins immediately to a new address and never use this address (both the segwit and legacy versions) ever again.

Open the file bitaddress.org.html in your browser (double clicking it should do that automatically) and choose the option for "Wallet Details". Enter your private key into the box and click "View Details". Scroll down and copy the string from where it says "Private Key WIF compressed". It should begin with a "K".

Import that string into Bitcoin Core. It is the private key that corresponds to the compressed public key. Then use addwitnessaddress on the imported address.

The transaction is just extremely large and thus has to pay a high fee. The actual fee rate is pretty low, but Bitcoin Core has a hard limit for what it considers to be an absurdly high fee. That limit is 0.1. Any transaction that pays more than 0.1 BTC in transaction fees, regardless of the fee rate, will be rejected with this error. It is not consensus invalid, it is just non-standard.

If you think it is hardware, check your RAM.

That's normal.

This is a clean shutdown.

Can you post what the log of when you started it up?

You can route payments through people, and have payments routed to you through people. You don't have to just transact with the other person in the channel.

In the short term on-chain transaction fees will likely decrease. In the long term, if more people use Bitcoin, fees will increase, but less so to levels that they would be without LN.

No, you only pay a fee when opening and closing a payment channel. Once the channel is open, you can transact freely (i.e. as many times as you want) with the other person in the channel at no cost. If you want to transact with someone outside of the channel but there is some route to them through LN channels, then you can use your same channel to pay that other person by routing a payment through other channels. This routing of payments will either be extremely cheap or have no cost, depending on whether node operators in the route charge a fee for being routed through.

If you are just going to make a single transaction with someone and you don't plan on using them to route payments to other people, then you should not create a channel for that. Just make a normal Bitcoin transaction.

No, it could not have.

Child Pays For Parent is called such because you are creating a new transaction which spends from the transaction that you want to change the fee of, hence it is a child transaction of the parent unconfirmed transaction. This child transaction contains a high enough transaction fee to pay for the parent. Hence Child Pays For Parent.

The other "adjust fee" method is called Replace By Fee. With Replace By Fee, you are creating a conflicting transaction that pays a higher transaction fee and replaces the original lower fee one.

So because there are multiple methods to increasing the transaction fee, it can't just be called "adjust fee".

If Bitcoin Core is not fully synced, you will not see any Bitcoin.

No, they should have a balance.

If you do not see a transaction history for those addresses, then that means that those addresses never had any Bitcoin, be that through normal transactions or from mining. If you do see a transaction history and there are transactions that send money from those addresses, then the Bitcoin has been sent elsewhere.

There is no need to do that if the wallet is not corrupted.

If Bitcoin Core is not fully synced, then let it fully sync. Once it is synced, you will know if you have any Bitcoin or not. If not, then there is no way to recover any of those Bitcoin because the private keys are probably gone and are not part of the wallet that you have.

Use addwitnessaddress on the legacy address that is imported. Then rescan the blockchain.

It is already implemented and almost done. It is actively being used on the testnet and multiple demonstrations of lightning on the Bitcoin mainnet have already been done. Once any of the major implementations of LN reach a release version and the Lightning 1.0 spec is finalized, you can consider lightning "released".

Not necessarily. If only one node's HTLC success transaction is broadcast, then all nodes in the route can take their payment and make their payment simultaneously even if one or more of them is offline.

I don't think the fee will be a centralization pressure. It will be a race to the bottom because there will be competition and it will be easy for new nodes to compete. So sure your "bank" charges 9.99 as their fee for one route. Now I create my own node and I get a couple of channels, not as much, but still many. If you route through me, you may still have to go through 4 other nodes. I can then charge 5 as the so the total route fee is 9 (5 + 4*1). Now that "bank" has to lower his fee to remain competetive, and so on and so forth. It will be difficult for any one node to get a monopoly and maintain it and make LN centralized. Even then, anyone can still make their own node and make channels without the permission of the "central nodes". So there will certainly be lots of competition and that makes it decentralized. You can close a channel without the other party agreeing to it, so you can switch to using a competitor at any time. You can even close your channel and fund the opening of a channel with someone else at exactly the same time in the same transaction, so you won't have to pay more in transaction fees.

Various network relay rule changes have likely made the transaction non-standard and thus not relayed, in addition to a very likely low or zero transaction fee.

Because the difficulty adjustment algorithm won't kick in until after the first 2016 blocks, so only after the first interval will your blockchain be different. If you change the retarget period, it will be the minimum of 2016 blocks and whatever you set the retarget period to be, i.e. if the retarget period is smaller than 2016, it will be that. Otherwise it will be 2016 blocks.

Can you post the debug.log? It usually contains more information than the dbLog.

It's an arbitrary large number.

No it is not. It would be reasonable for you to open a channel with your employer who also has a channel open with that coffee shop. Your employer would pay the transaction fees for you, and then you can pay the coffee shop. Later the employer would pay your through that channel.

No. As I said earlier, LN is not for spending from small outputs once but rather spending from large outputs in small amounts many times. The common use case scenario is that you put in (for example) 0.01 BTC into the channel with the coffee shop. Then over the course of months or years, you slowly pay the coffee shop 0.00001 BTC per coffee but without actually making any on-chain transactions and paying their transaction fees.

This topic has been moved to Trashcan.

Trashcanned upon request.

Changing the difficulty adjustment calculation to target 5 minutes should make it not be wiped out after the first 2016 blocks. The first 2016 blocks can still be the same as Bitcoin's and could wipeout your chain.

Bitcoin uses little endian numbers, so these need to be reversed.

Otherwise, that looks correct.

I don't think spam transactions have been large transactions, rather they are small ones and there are lots of them. So this wouldn't help. Perhaps if you inverted it, smaller transactions have a higher PoW. But then spammers would just make large transactions. And if you penalized large transactions, they'll make smaller transactions.

Furthermore, as I said earlier, getting an ASIC or a GPU or two would basically make this completely useless unless you can somehow adjust the difficulty to the volume of transactions a person is creating. If I were a spammer, I could get an ASIC and just churn out spam anyways because the ASIC is going to blow through whatever difficulty you set unless that difficulty is specifically being adjusted for my spam.

Now you might say that getting an ASIC or GPU is costly and thus prohibitive, but it has been theorized that many of these spam attacks are coming from miners who want to increase the fee rate and thus increase their mining profits. So if a miner is mounting a spam attack, they can take a single ASIC machine that is being used for mining and repurpose it to get around the PoW limitation. They would still be able to churn out spam transactions as quickly as before.

Lastly, as ranochigo said, your proposal would have a detrimental effect on the UTXO set. You would be encouraging the creation of UTXOs when what we want to do is encourage the consumption of UTXOs. By making large transactions costly, people will make smaller transactions and likely with change (so likely 1 input and 2 output transactions) which will result in a net increase of UTXOs. This is not very good for Bitcoin, and it has the effect of grinding down one's UTXOs into dust thus making it hard to spend any Bitcoin later.

Nice find!

I can't imagine that Bitpay is going to leave that there any longer though, it seems like a mistake for them to do so and now that it is publicly known, it will probably go away.

Also, this link
does not work, probably because the invoice expired already.

You can use the one I wrote: https://github.com/achow101/payment-proto-interface