I understand the network like this.
1) Sender is searching the best route through all nodes to reach the target.
2) Sender is encrypting the selected route node by node (onion routing)
3) Sender send coins to the first node using a payment channel between sender and first node
4) The next node decrypts the follow up node and continue sending coins to the next node over the next payment channel
5) continue with 4 until the target node is reached.
In my understanding, whenever I send something over the payment channel, this transaction is completed and not reversible (this is maybe the point where I'm wrong).
So, when I have 10 nodes in my selected route, and node 5 in my list is down. How does the network make sure, that the 4 nodes before are doing a rollback to give back the coins to the sender, so the sender can try a different route.
That's not how payment routing actually works. That's just the messaging protocol to transmit some information between nodes. The actual payment part works through Hashed Time Locked Contracts (HTLCs). So node A offers a HTLC output to node B. In order for node B to spend from that HTLC (thus being paid by node A), he needs to provide the preimage to some hash in addition to his own signature. After some timeout, node A can take the money back with a signature of his own. In LN, the HTLCs are used to make the payments between the nodes. They use the same hash so they all have the same hash pre-image required. So if any one HTLC is spent, all HTLCs in the route can be spent since the hash pre-image is revealed during the spend. If the hash preimage is never revealed, then the coins are never sent to the other party. This makes it atomic. As a shortcut (to avoid on chain transactions for each HTLC) LN uses the onion routing method you described. The hash preimage is given to the recipient by the sender and that is transmitted to each node in the route so that they all have the hash preimage. Once both nodes in the channel have the hash preimage, they resolve the HTLC off chain. If some nodes are not able to transmit the hash preimage to settle the HTLC off chain, then the node that was able to settle with one peer but not the other can settle on-chain, and in doing so, reveals the hash preimage for the remaining nodes to settle (either on chain or off chain, as necessary). That node is incentivized to settle on chain because he would actually be losing money by not settling. |
|
|
|
1) As far as I know and can see it should do name resolution, but since this is the 1st time I am actually doing it this way does it, or am I just assuming that it does?
[ You are assuming that it does name resolution, but AFAIK, it does not. Just because a different software does name resolution (indicating that the machine is capable of doing so) does not mean that bitcoin-cli will do name resolution. |
|
|
|
|
The consensus rules are what define a blockchain. You cannot create a blockchain without the consensus rules. You need to implement your consensus rules in a software that is then used to create a blockchain.
Typically people who are doing this will just clone an existing coin and modify it. You will need to understand how that coin works and what your modifications must be. This isn't something that is beginner friendly nor is there a beginner "how to do" guide available. This is specialized knowledge that not everyone can do.
|
|
|
|
|
Both the file db.log and the directory database are files used by the BDB database engine. The directory database is a temporary directory that is used to store data about the wallet while the wallet database is open. If Bitcoin Core is uncleanly closed, the BDB database will also be uncleanly closed. If it is uncleanly closed, then in order to open it again without having any problems, you must have the database directory as it contains some BDB state data. If they are separated (wallet.dat moved out or database is deleted), then the wallet database can be corrupted and private keys corrupted. This can result in a loss of funds.
Having separate wallet directories containing their own database environments allows for better dynamic wallet handling and a failure to close the BDB environment cleanly may only just effect one wallet instead of all wallets.
|
|
|
|
This topic has been moved to Trashcan. Duplicate |
|
|
|
|
What version of Bitcoin Core are you using?
Try updating Armory.
|
|
|
|
What's the input size for non-Segwit P2SH?
It depends on the script wrapped by the P2SH address. It could be 0 bytes, or it could be 10000 bytes (the maximum scriptsig size). |
|
|
|
What's the actual-bytes transaction size (or, well, per-input size) in the case of P2SH-P2WPKH versus P2PKH or "legacy" single-key P2SH?
The actual byte size for a P2PKH input is 148 bytes. For a P2SH-P2WPKH input, it is 171 bytes. For a P2WPKH it's also 148 bytes. However the actual byte size doesn't really matter. Blocks are not limited by size but rather by weight. And transaction fees are actually by weight or virtual size (weight/4) and not actual size. So th weight for a P2PKH output is 592. For P2SH-P2WPKH it is 360 and P2WPKH it is 268. So as you can see, the segwit inputs consume less weight and are thus cheaper to spend. Is it currently possible to sign a message with a P2SH-P2WPKH address?
No. There is no standard for signing messages with segwit addresses yet. That's something that is being worked on. Note that messages aren't actually signed with an address. Rather they are signed with a public-private key pair which can correspond to multiple addresses. Your wallet software will calculate the public key for a message and convert that into an address. A wallet could just as easily show you a P2SH-P2WPKH or P2WPKH address instead of a P2PKH address when it is verifying a signed message. What needs to happen is a specification for signing messages with a script which can thus be generalized to signing with an address. Such messages and signatures would actually correspond to addresses and not a public key which your wallet just turns into an address. |
|
|
|
|
What exactly are the lines you changed (as in post the code snippets for your changes).
|
|
|
|
But I remember I asked about symlinking method to separate chainstate folder from blocks folder and also other members also asked about it and basically the consensus was that it was very unsafe and would corrupt the block or chainstate files... what has changed since then? Or when you say possible, you mean it can be done but it is still unsafe even with the latest version? Im just not sure what you mean.
I think you mean that nothing has changed and it's still unsafe but I want to be sure... but I predict that im going to be stuck with an HDD.
Nothing has changed and it's probably still unsafe to symlink the blocks folder. |
|
|
|
What's the point of not keeping it? Some people will only accept legacy payments and they have they right to do so, and people have their right to use legacy at any time.
It would not be any more confusing than having that "Generate Bech32 address" button which already exists there.
And like I said, this could be hidden by default and shown if you enable advanced features on the menu.
In any case, noobs in general don't use full nodes. Anyone using a full node knows what that is anyway.
The idea to use dropdowns came up frequently in discussions on how to support getting segwit addresses in the GUI. We decided to stick with the checkbox approach because we want to encourage users to use segwit. The only reason to have the checkbox is to let people use bech32 addresses when they want to and default to backwards compatible p2sh-segwit addresses. There's little reason to use legacy addresses except out of principle (i.e. those who hate segwit). For such people, they can start Bitcoin Core with addresstype=legacy, and hopefully those options will be available from the settings menu too (there's an open PR for that). |
|
|
|
|
Did you reset your datadir before trying with the new genesis block? Reset as in delete the blocks and chainstate folders.
|
|
|
|
So nonce and genesis hash is different with [ assert(consensus.hashGenesisBlock == ] part?
Of course it will be, that's how mining works! The nonce is part of the block header which is used for computing the block hash. It is what is changed to make a valid proof of work. Your nonce and thus the genesis hash were invalid, the script produces values that will be different which will be valid. So then this means genesish0 is not work with current source? (litecoin 0.15.1)
No, it worked correctly, just that the script is a little wrong. It still found a valid block, but it printed the wrong value for the block hash. You can see that the block hash was printed in your error, it's 0000c978c4bf731c7e48018bc21f658b37394b5d18bd2ceca383768387578d76. So you need to set your genesis block assertion to that value. |
|
|
|
With the SegWit2x, the existing bitcoin transactions will not be congested (at least 2-3 years), and then there will be more intelligent two-layer protocols. .
Segwit is not the same as Segwit2x. |
|
|
|
so essentially I think both txs are treated as having higher than 1 s/VB tx fee
while bc.info is displaying them (inaccurately) having less than 1 s/B
That's correct. Bitcoin Core does things in sat/vByte, not sat/byte (although things are still named the old way). |
|
|
|
Will this ever be possible
It should be possible to do now with symlinking. But to actually have configuration options, I'm not sure. and how long are we from seeing that?
No such time estimates can be given since no one is working on it and it is not a priority. I remember asking a long time ago about wallet separated from root folder and got told it was not possible and unsafe, yet it is now possible, so I would like to ask about this.
What people were asking for in the past is not possible and is still unsafe. What happens now is only possible because of datadir structure changes that move wallet things into their own separate directory. |
|
|
|
You still have failed to generate a valid genesis block. Reindexing isn't going to do anything. Since you seem to be having such a hard time creating the genesis block, why don't you use a script like https://github.com/lhartikk/GenesisH0 to do it for you? |
|
|
|
Kewl  would i need to add server=1 on the full node for it to work? right now it has no .conf file running gui version No. server=1 is only necessary if you are planning on using the JSON-RPC interface. |
|
|
|
got a question, can i addnode= from local LAN that's running a full node to my spv wallet to sync from alot faster then say using the internet? Reason i run 2 copies is i hate copying that 150 gb of data over my network ~ 30 mins to backup the entire blockchain  Sure, there's no reason you can't. You can use connect instead of addnode to guarantee that you are connected to your local node and syncing only from it. |
|
|
|
|
Show Posts
