This transaction spends from an unconfirmed transaction and which also spends from another unconfirmed transaction. This one cannot confirm until those unconfirmed ones confirm too.

Because these spend from an unconfirmed transaction, they cannot confirm until the unconfirmed one does too.

Do you mean multisig for the 2 factor authentication or just normal multisig to have multiple parties required for a transaction to be validly signed?

For the former, you can use Electrum with the TrustedCoin service. BitGo also offers a similar thing.

For the latter, you can use basically any modern wallet software. This includes Electrum, Armory, Bitcoin Core, etc.

That happened at version 0.10. Since 0.10, syncing the blockchain has gotten much faster. Of course there are performance improvements that happen with every major version that make syncing the blockchain faster and faster.

Nodes are machines that are part of a network. In the case of Bitcoin, it means machines that are part of Bitcoin's peer to peer network. They receive and send blocks and transactions.

Nodes can be broken down into several types: full, pruned, and SPV. A full node is one which receives all transactions and blocks, fully verifies each one, and relays them. It also stores the full blockchain. Full nodes can serve the entire blockchain to anyone who wants it.

Pruned nodes are like full nodes except they don't store the full blockchain. They still verify and receive all blocks and transactions and relays them.

SPV nodes are nodes which only receive blocks and transactions, and not necessarily all of them. They typically only receive ones which pertain to their wallet. SPV nodes are incapable of fully validating all blocks and transactions and do not relay blocks or transactions unless it originated from that node.

Masternodes are a certain type of node for altcoins that have special abilities. Bitcoin does not have masternodes.

Post your log files.

Try using 0.96.4 RC3, available here: https://github.com/goatpig/BitcoinArmory/releases/tag/v0.96.3.992

The code that Bitcoin Core uses for ecdsa operations on the secp256k1 curve can be found here: https://github.com/bitcoin-core/secp256k1 (it's its own library). There are comments throughout the code and some additional documentation on the readme that should help you understand what it is actually doing.

Can you post your debug.log file?

This looks more like a problem with your X server rather than Bitcoin Core.

When a new commitment transaction is made, the old one should become invalid. However commitment transactions are not broadcast to the network, rather they are kept private and only broadcast when you want the channel to close. But because all commitment transactions are technically valid, we need some way to prevent people from broadcasting old commitments as they would effectively allow them to steal money. That's where the revocation key comes in.

During the process to create a new commitment, the revocation key for the commitment being invalidated is revealed to the other party. In this way, if you were to broadcast the old commitment, the other party would have the revocation key and can thus broadcast a punishment transaction where they use the revocation key to take all of the funds in the channel.

The revocation key itself is basically the combination of two keys. What effectively happens is that both parties provide a public key at commitment transaction creation time, and those public keys are combined to create the revocation public key. Then when the commitment is replaced with a new one, the party who is having their commitment revoked (remember that each party has their own personalized commitment transaction and the revocation keys are "personalized" for each commitment) reveals their revocation secret to the other party. This secret is combined with the other party's own revocation secret to create the full revocation key. In this way, the party who would have his commitment revoked with that key does not have access to the full revocation key.

Lightning is supposed to be "distributed", and it has thus far shown to be fairly distributed.

Jonald's assumption of what lightning would actually be like is wrong.

No, it can't. MuSig itself cannot be k-of-n, but it can be used in applications that are k-of-n. Additional work must be done to make that happen, and it can and will be done where the participants in the multisig know who the others are and have proof that there are actually n people in the multisig, not some other number.

Again, you don't seem to understand what interactive and non-interactive means. It has nothing to do with "seeing the backroom players". All that interactive means is that the people in the multisig prove that they didn't make up some bullshit public key. Yes, they will see everyone involved. But you can still do that with a non-interactive scheme. Work is still being done on this topic to create a secure k-of-n scheme which avoids rogue key attacks (which is the class of attacks you are describing).

You seem to think that we don't know that k-of-n needs more work to make it secure. You seem to think that we don't know that the participants want proof of the other participants. Well, here's the thing, we're not stupid. All of the stuff that you thought of are things that we already thought of and are working on ways of solving. It's not like MuSig is immediately ready to be used for all Bitcoin multisig transactions and that was never claimed to be the case.

If you read the paper, you'll notice in the section on Applications to Bitcoin, k-of-n is briefly discussed. In it, various schemes are briefly proposed that would avoid rogue key attacks but still allow for non-interaction and secure-ness. Things like just not doing key aggregation at all for an actual multisig or using merkle trees to prove the existence of keys.

---

I'm done with arguing with someone who refuses to even understand the technology he is arguing about. Back to my ignore list you go.

This topic has been moved to Trashcan.

Duplicate

It's cheaper if you open your channels in the same transaction, which, by the way, is possible.

Also, if you are a party in a channel, you don't necessarily have to fund the channel. One person can fund the channel, and the other person just has 0 balance in it initially. In fact, that's how the protocol currently works. So you could actually have many channels, of which many were not funded by you.

Strange that he decided to setup the channel with B then because in the "lets make a channel" message, both A and B would have explicitly stated the terms of their channel. This includes the maximum amount that B is willing to transmit for A (and vice versa), the transaction fees to be paid in the commitment (can be updated later), who is funding the transaction, etc. All of this is done before any transactions are made so that A and B know exactly what they are getting into. It's strange that A would choose to open a channel with B if he knew that B would not be open to transmitting 10 BTC to someone else.

A can see what channels X has open, and he can see that X is also connected to Y and Z, as well as the hub. If he sees that X is advertising 10 BTC transmission, but has multiple channels open where he could, in theory, have more than 10 BTC attempt to be transmitted and his other channel only has 10 BTC, A might want to consider not opening a channel with X. Of course this would also all happen before any transactions are made.

Alternatively, A could not put all of his life savings in one channel. Instead he could open 2 or 3 channels using the same on chain transaction which might only cost him another 50 cents to open 2 additional channels. If he does that, he will be better connected and have more opportunities to be able to send his money.

I never said it was. What I am saying is that many of Lightning's detractors don't seem to understand how it works and like to ignore the fact that it's shown to be an improvement over the current on chain situation. This has thus far been shown on both mainnet and testnet where people are able to make payments that are way below the dust threshold and make payments to others in the network with little (on the order of single digit satoshis) or no fees.

I suggest you do that too. I am always wearing my "critical thinking" hat, but you never seem to be. It's always the "I have to shit on everything that Core does and everything that is not on-chain" that you seem to be wearing. I don't have to promote anything nor am I being paid to promote anything. Hell, LN is not even part of Core and we don't really have an interest in integrating it into Core. The people working on LN are completely different from those working on Core.

What do you mean "has its own wallet file called Documents.dat"? Bitcoin Core does not create a file called Documents.dat. The only way that would be created is if you have configured Bitcoin Core to create a wallet file named such.

What are the contents of your bitcoin.conf file?

What do you mean by "original curve point"? Do you mean the generator point? If so, that's part of the curve parameters. You can only know that by knowing what curve you are using and its parameters. Given just a public key, you cannot know the curve parameters.

I don't think a node will serve blocks to any other node until it is fully synced. So if your first node is not synced yet, you should wait for it to be fully synced and then try again with the second node.

Bitcoin is the name of the coin. Bitcoin Core is a full node software for Bitcoin. They are not two separate coins, but they are different things. You do not create an account for either Bitcoin or Bitcoin Core. You need a wallet, which Bitcoin Core is.

Try using 0.96.4 RC3 available from here: https://github.com/goatpig/BitcoinArmory/releases/tag/v0.96.3.992

No, that is not what interactive means.

In traditional cryptography, interactive means that the participants in the multisig must verify that the other participants actually control the private keys to their public keys, not that it is n-of-n. Non-interactive does not mean that it is k-of-n, it just means that there is no key exchange and verification protocol that must be executed.

Anyways, MuSig is specifically an n-of-n multisig scheme as it is a multisig scheme in the context of traditional cryptography.

The same is with current multisig using P2SH. Hell, you don't even know whether a given P2SH address is multisig or not, so if you are a participant in any multisig, you should always be asking for the redeemScript, or, if using something based on MuSig, you should be asking for the public keys involved and make sure they calculate to the given aggregate public key.

This is completely incorrect, did you even read the paper or the linked blog post?

As I said earlier, MuSig is only a n-of-n scheme so this concern is completely invalid. To do k-of-n, additional work is required.

k-of-n is out of scope for the paper. MuSig is only n-of-n, but with additional Bitcoin specific things, can be done in a k-of-n fashion.

Currently the network is still fairly small. But if you look closely, the network is really not a hub and spoke network. Even if many people have channels with these "main hubs", many of those nodes also have channels with other nodes too. The "hubs" thing right now is probably because there are only a few services that accept LN on mainnet and people are just connecting directly to them in order to pay.

I suggest you take a look at how LND does autopilot mode. It takes in various inputs and uses a model to figure out what channels are the bets to open. You can read about it in the release notes here: https://github.com/lightningnetwork/lnd/releases/tag/v0.3-alpha

LND does not need much more resources than those that are already required for running a full node (because you need a full node). You can also not run a full node and instead run it in SPV mode which uses BIP 157.

The current protocol limits channels to 2^24 (16777216) satoshis. There is no minimum funds; you can open channels or request channels to be opened where you provide no funds into the channel. IMO putting 0.01 BTC in a channel is reasonable.

At least on testnet, there doesn't seem to need much maintenance. The available software are capable of handling things automagically.

LND has the option to use Bitcoin Core as the full node backend.