Nullius made one here: https://bitcointalk.org/index.php?topic=2934774.0
Supports both nested segwit and native segwit (Bech32)

The third parties are called Watchtowers and it's actually possible for the whole scheme to be trustless

Bitcoin transactions are irreversible, so you can't get them back


But if you know HOW it happened you can prevent a future occurrence.

How do you usually access your wallet? Do you use the website on a PC? Or a mobile app?
Were you given a seed phrase (a set of 12 or so words)? How did you store the seed?
If you're using a PC then you should do a full scan of it for malware.

You can include the amount you want the customer to pay and the purpose for payment also (payment label).
It's all defined in the URI scheme in BIP 21

Yes, that means you have a clipboard malware that changes any BTC address you copy to your clipboard to one of the hacker.

Do a full scan of your system with Malwarebytes -- or better still, backup your important filesz wipe the hard drive and install a *Unix OS.

My point exactly; you don't need a POS machine because you're dealing with cryptocurrencies.

Exactly, yes.
All the customer need is a crypto wallet.
All mobile wallets support QR codes so you just need to scan the QR code.

POS machines connect to a centralised backend (usually bank clearing)
Cryptocurrencies are the exact opposite of that.

The only thing similar is payment processors like Coinbase or Bitpay, which is already what most merchants use.

You'll scan a QR code, and send bitcoins to that address for your purchase, and in the backend, either the bitcoins go directly to the merchant's address, or through the payment processor and they get settled in fiat.

"No inputs" means that there are no (confirmed) UTXOs for that address, meaning there are no bitcoins there.
Are you sure that address has bitcoins?
Are you sure you're sweeping the right private key?

Yes, that's how it works.
It's just between two parties. There are no nodes that store all the commitment transactions between peers.

No.
If you try to cheat the system, you'll be punished by losing your funds in the channel.
Lightning network transactions persist as channel states, if you try to publish an old channel state (which won't be mined because  it's timelocked) then your counterparty will publish a transaction that takes your funds in the channel.
Read the lightning network whitepaper
It's documented there.

yes, this is correct.

Yes, that is if you do not specify an output for the change address -- there is no field in a bitcoin transaction for the fees; they are implied as the difference between the inputs and outputs.
However you can use the "from" address as the change address.
So if you're spending 0.1 BTC of a UTXO of 1BTC, you can have two outputs: output 1 is the destination address 1Destination and you can use the same "from" address to receive the change  (1FromAddress)
I don't understand what you mean.
Perhaps you're using just one address and the change address is being sent back to the original address (terrible for privacy)
Can you post a sample TX ID?
For example, this transaction the change goes back to the "from" address.

Was it in Sipa's talk in Scaling Bitcoin in Milan?

A transcript of the video above (Pieter's part) can be found here

Or this Blockstream post?

The Bitcoin Core developer guide for segwit wallets is a good place to start.

Competing blocks are not resolved immediately; other miners have to vote with their hashpower ON the block that they consider valid.
Also, blocks have to reference the previous block header hash to build upon them.
There are 3 miners: A, B & C.
Miner A & B found a valid block almost simultaneously and "published" their blocks
Right now there's a temporary fork in the blockchain.
Miner C then found and  published a block building on miner A's block.
The blockchain including miner A's block is the longest chain with the highest cumulative difficulty because it has the difficulty of the previous blockchain + that of miner C's block .
If other miners "vote" by building their block tip on miner C's block, then it becomes the valid block chain and the block by miner B gets orphaned.

Let's use numbers.
Let's say The current block height the miners are building on is block 100 with block header hash 000....100x
Then miner A finds a valid block that builds upon this, which should be block 101, with blockheader hash 000...101a
However miner B also finds a valid block also building on block height 100 with hash 00..100x, which is also a competing Candidate for block height 101.
Right now there are 2 block 101's -- that of miner A and that of miner B, and there's a temporary bifurcation in the blockchain. full nodes will store both blocks till it is resolved.
Then the miners will vote with their hashpower on the block they consider to be valid.
If miner C builds on miner A's block 101 with hash 000...101a and finds a valid block, 102, then the blockchain of miner A's block is longer, and it also has the highest cumulative proof of work (measured in the difficulty of the block), so his block is "more valid" than B's and if other miners agree with miner C and extend the blockchain by building on miner A's block, then miner B's block will get orphaned by the nodes.

In a rare scenario (eg the 0.8 bug) where after miners up to block 104  Are mining on the block found by A, and other miners decide to mine on the block found by B instead and overtake the length of the chain of A with higher hashpower, then the blocks found from 101 - 104 built on the block found by A will be orphaned and the blockchain will reorganise to the new chain with the highest cumulative proof of work.
Therefore a transaction mined in miner A's block 101 that now has 3 confirmations (3 blocks built on top), will be orphaned and invalid if the transaction was not included in any of the subsequent blocks found.
This is why you should wait for 6 confirmations before you consider a transaction valid even though block reorgs usually do not have a depth of more than 2 blocks.
It's also why the Coinbase maturity time is long (100 blocks)

---

The important factor in determining the valid chain is the one with the MOST proof of work, not the longest chain alone  or else it would be trivial to fork bitcoin, reduce the difficulty and  mine several blocks ahead of the main chain, forcing a block reorg of the "true" chain to my fake chain.

Not right now, no, but there are plans to make it work with a pruned node
Yeah, Neutrino isn't mature enough for mainnet yet.

Stop LND with Then backup .lnd folder
Restoring the folder should preserve your channels and peers.

You don't need to worry about changes in IP address; your node will gossip the change to your peer and other nodes in the network.

He doesn't "receive a block to mine" , he crafts a candidate block with a Coinbase transaction and with transactions aggregated from the mempool.

This is false.
Miners do not have their own separate blockchain from the rest of the network.
Also, the miner is rewarded iff his block is valid according to the consensus rules; he finds a nonce when hashed with the Merkle root, timestamp, etc, gives a block header hash lower than the target hash; no other miner releases a completing block (valid block with the same block height).
When all the conditions are satisfied, then the Coinbase transaction he crafted (including the block reward) becomes valid -- and can only be spent after 100 blocks.
He doesn't have a chain, just a block which will either be added to the main chain or not depending on if he follows consensus rules.
Any block that hasn't been added to the blockchain IS NOT part of the block chain; it's just a candidate block.
So they are many CANDIDATE BLOCKS but just one blockchain.
No, not really.

His block only gets orphaned if after he published his valid block, another miner publishes a block with the same block height but higher cumulative difficulty, if he doesn't find a block in the first place then he's not part of the blockchain and so his block can't get orphaned.

Miners mine on the TIP of the main chain.
Miners craft candidate blocks on top of a block that's on the blockchain.
Until a miner finds a valid block and publishes it and other miners  mine on top of it as the TIP of the next block, his candidate block is NOT on the blockchain.

For better understanding of the subject read Andreas' chapter on mining in his book Mastering Bitcoin.

The address starts with "3" so it's a P2SH address (most likely P2PWKH wrapped in P2SH,  aka Segwit address)
Blockchain.info wallet does not support Segwit AFAIK.
You'll have to import the private key to another wallet that supports Segwit eg Electrum.

You're flirting with disaster.
Why would you want to do something which you haven't the faintest idea about?

You're talking about "buying a software" -- what if the person that coded the software has a backdoor in the software/script, how would you know?

Stick to what you know.

If you really want to go ahead with it then employ a competent Dev  team to code one for you.
If you want a good job, then it won't be cheap.

Have you imported the wallet.dat into bitcoin core?
Is there a passphrase?
Do you have it?

You don't need to download the whole blockchain to check.
Download bitcoin core software
On the debug console, run or to get a list of addresses controlled by the wallet

Check the balances of the address on any block explorer.

If you want to export the private key of any address into an SPV wallet like Electrum
Unlock the wallet (if it is encrypted with a passphrase)

Then use dumpprivkey to dump the private key of the address
Eg
This will bring up a string of alphanumeric characters starting with either 5, K, or L
That's your private key, that's how you can spend bitcoins, if you share it with someone else then they can spend your bitcoin, if you lose it then you'll most likely lose your bitcoins forever.

---

You said
Which makes me doubt you have the passphrase for the wallet.dat in the first place.

The instructions for the BIP39 tool:

You'll need a Linux system for this. Ubuntu is easy to use.
In a Linux OS, open a terminal window and type the following (press enter after each line):
 Then let it run.
PS do not insert the brackets in <your 24 word seed> or <bitcoin address>

An example usage is:

Replace "correct horse battery staple" with your seed.

---

As for the ypub tool, Blockonomics block explorer supports Segwit HD addresses so you can search ypub: http://www.blockonomics.co/

You can also use Shivaenigma's port of pycoin that has support for ypubs.
Run
Replace ypub with your ypub
Replace 0/0 with the node you're checking
Replace 5 with the number of addresses you want to create

The Lightning Network is NOT a soft fork; it's a layer on the bitcoin blockchain.
In fact the bitcoin blockchain has no concept of the Lightning Network at all.