As far as I understood a LN Channel is open and closed by their participants by broadcasting and confirming transactions on the chain, so they only pay those transactions fees and not all the other they may do while the channel is open.
Yes. If that is right, the LN would work only for recurrent payments and not occasional transactions, right?
Kind of. Having an open payment channel with one party is really only good for recurring payments. However the lightning network expands beyond the one channel. You can have a channel open with someone who has a channel open with other people, and they have channels open with other people and so on. One of the main ideas of LN is that you can send occasional transactions by routing a payment through multiple payment channels that people have open with each other. Suppose Person A has a channel open with B, and B has one with C. If A wanted to pay C, they could send money to B and B sends money to C via their respective open payment channels. The transactions used for this sending are special and make it so that the money will only actually move under specific circumstances. These transactions are called Hashed Timelocked Contracts. They make it so that B can only get the money from A if they have forwarded the money to C. |
|
|
|
My question is - is Lightning Network really going to lock our funds for so long time that its going to cause problems?
No, it is not. When you "lock" your funds in a LN payment channel, you can still spend those coins, albeit only with the other party in the channel. However with LN, if that other party is connected to other people via payment channels, you can make payments to those other people and the people they are connected to and so on and so forth. So your funds aren't "locked"; you can still spend them and move coins to other people that have LN channels open. Furthermore you can choose to close a channel at any time that you want and be able to access your coins as soon as the channel closing transaction confirms. There is no set time limit on a channel and there is no minimum time required for a channel to be opened. Cause it seems to me obvious that hackers could fail transactions for purpose and block the network.
What do you mean by "fail transactions"?
The lightning network is different from DASH and IOTA in that it itself is Bitcoin, not an altcoin. With LN, you are moving and using Bitcoin so the value you move is fixed and does not change. If you were to use an altcoin in the same manner, you would risk losing money as the altcoin's value compared to Bitcoin's changes. Furthermore, many of the security risks and potential attack vectors are fairly well known because LN uses Bitcoin and Bitcoin's security risks and potential attack vectors are well known. With an altcoin that uses some crazy cryptography that may not necessarily be secure (IOTA had some broken cryptography which were pointed out in a security review done by 3 MIT DCI researchers) does not have known security risks and potential attack vectors. |
|
|
|
So, Lightning is not a UAHF, but is going to pass because Segwit already was implemented? It's a done deal, or....am I totally missing something?
Lightning is neither a hard fork nor a soft fork. It will be deployed on the main network because Segwit has already activated. There is nothing to "pass". Lightning is not a consensus rule change; nothing needs to be activated or passed in order for it to be deployed. It just needs to be implemented. By deployed, I mean used. |
|
|
|
Hello. I used Feebooster as receiver (created raw tx and signed) but it seems that it decoded Hash 160 into the wrong address, not the one I filled in (with version byte of 0x01 for P2PKH) but it sent to the wrong one (version byte of 0x05 for P2SH). No idea how and why that happened.
Funds were sent to a different address (starting with 3) than the one I filed in, and bot have same Hash 160.
Post the raw transactions, screenshots of what you entered, and the txids of any and all transactions involved (including the one you are bumping and the bumping tx). |
|
|
|
First of all, please do not use or refer to the Bitcoin Core 0.8 codebase. It is extremely outdated and insecure. Could anyone help me out in figuring out what the numbers in the first one mean.
It is just making a script to put in the scriptSig of the only transaction in the genesis block. The stuff in the script mean nothing and have no consensus meaning except for the fact that they must be there otherwise the genesis block's hash will not match what it is supposed to be. Push this number to the scriptSig. It just happens to be the decimal version of the nBits of the genesis block. Push the number 4 to the scriptSig. << vector<unsigned char>((const unsigned char*)pszTimestamp, (const unsigned char*)pszTimestamp + strlen(pszTimestamp));
Push the character array pszTimestamp to the scriptSig. This character array is just the string of "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks" And for the second one, where is that hash from??
That is not a hash. That is a public key. It is a normal Pay to Public Key output.
The forum is doing something weird with the code blocks here. |
|
|
|
From what I am reading, what is stored on the individual computing nodes is a history of hashed transactions and stuff.
No, not the hashed transactions, the full transactions. And the block headers for the block that a transaction is in. At some point in the past a miner received a coin as payment and a block starts ( a linked list, some structure of some kind) and grows keeping track of transactions.
No, that is not how the blockchain started. The first block (known as the genesis block) was created by satoshi and hard coded it into the software (and it still is hard coded). You cannot receive something as payment if it does not yet exist; coins only exist because blocks exist. The linked list known as the blockchain is built off of the genesis block. 1) Does this mean that all transactions since startup are still in the system?
Yes. 2) Will they all stay there for the next 25, 50, 100 ...... years?
Yes. They have to. |
|
|
|
Yes I know, but I meant only segwit. I know Core is not supporting 2x.
So which is the first version released by Core with segwit?
Bitcoin Core 0.13.0/.1 (0.13.0 had it implemented but had no deployment mechanism for segwit. 0.13.1 had the actual deployment parameters) Block weight is a segwit specific thing and is only implemented and defined in segwit. Same thing for comparison schema or slide ... are there some pictures showing block data structure and verification rules changed before and after segwit?
Thanks.
Read BIPs 141, 143, and 144 |
|
|
|
|
Set some hard coded seed nodes to be nodes that you know will be up for a long time.
Set up a DNS seeder and add that to the hard coded list of DNS seeders.
|
|
|
|
This topic has been moved to Trashcan. Duplicate |
|
|
|
Cool, thanks for your reply.
When has it been released? I've compared bitcoin core 0.15.0.1 with 0.14.1 and MAX_BLOCK_WEIGHT (should be the right constant to check) is the same.
Does anyone know where to find a document, pdf, slides, ... with a graphical comparison schema of the differences before and after segwit?
Segwit and Segwit2x are not the same thing. Segwit has already activated, segwit2x has not. Bitcoin Core does not support segwit2x so you won't find any code related to segwit2x in the Bitcoin Core codebase. |
|
|
|
The SSS implementation in Armory is completely unrelated to that. It also predates that by a few years. |
|
|
|
@anonymoustroll420: strictly speaking it is not a blocksize increase. Stuff has been moved in another place to make room for other transactions.
As far as I know blocksize is the same and that's the reason for "2x or not 2x". But this is another story.
No, that is strictly false. Segwit is a block size increase; the size of a block message can be up to 4 MB now. 2x is yet another block size increase; it makes the maximum 8 MB. |
|
|
|
|
You are using a version of Bitcoin Core which is incompatible with your version of Armory because it has segwit enabled. Either downgrade to Bitcoin Core 0.12.x (and redownload the blockchain) or upgrade Armory to 0.95.1 or greater.
|
|
|
|
2x is a "physical" blocksize increase to 4-6MB, not just 2MB. Regular SegWit already leads to 2-3MB blocks.
Thanks just to clarify, when I say 2x, I know segwit gives effective size, but I mean the commitment to make base blocks bigger so we can really make the "spammers" run ou of money and keep on chain fees lower, and give consumer choice. With 2x, the worst case size is ~8 MB. We don't know how such large blocks will effect the network. It could increase orphan rates, it could cause many nodes to drop off of the network because they can't handle the additional load. We don't know if the network can handle such larger blocks. Just because your internet connection can and your machine can handle the load does not mean that everyone around the world who is running the node can. They may be restricted by things like the Great Firewall of China which may find larger blocks easier to spot and thus make Bitcoin easier for them to block entirely. Furthermore larger blocks can lead to miner behavior that is detrimental to the network. If the mempool is constantly cleared by a new block, then miners may be more incentivized to perform fee sniping instead of moving the blockchain forward. That is not good for the network. Why does the "base block size" need to be bigger to stop spammers? You don't think they aren't going to also use segwit? Spammers can use segwit and pay less in fees than they would with a non-segwit transactions, and make more spam that fits in a block. If you double the maximum block weight, you depress fees even more and let spammers pay even less to spam transactions. Also on point what then isentivices miners as block reward drops if they don't have enough transactions on chain?
Having more transactions on chain does not necessarily correspond to having more transaction fees in a block. If the general idea is that larger blocks will decrease fees, then that means that more transactions need to be made at a lower fee rate in order for total transaction fees to match the fees for when blocks were smaller. Currently transaction fees are pretty low anyways except the times when people are spamming transactions (and it is very noticeable when that happens because the number of transactions in the mempool at a certain fee rate inorganically shoots up). |
|
|
|
ok thanks....I was kinda thinking along the lines of using the signed specified address as a requirement combined with the part of the priv key, hashed or otherwise, that then produces the whole private key, but only as a signed transaction for the sending address.
That way you would never have access to the privkey of the sending address, excepting for using the signed predetermined receiving address.
...I may be way of base here, but it seems possible?
or put another way, like a contract function that says, if you enter address 2 and your part of the private key or private key, then we will use that to sign the whole transaction and send it off to address 2. The contract only works in it receives the address 2 and your signed address 1.....?
Again, inputs and outputs are unrelated to each other. Inputs cannot access any data outside of the input itself. Inputs have no idea what the outputs are and cannot access the outputs to do anything. Also, there are no such things as addresses to the Bitcoin network. Only transaction outputs. Addresses are just an abstraction for us humans. |
|
|
|
|
This thread is being locked because the OP has not responded in a while and it is just becoming full of spam.
|
|
|
|
Does this mean it will pass since segwit is already activated ?
Yes. The Lightning Network will be deployed on the main network without 2x. It only needs segwit which has already activated. It is not a consensus rule change so it does not require a fork and does not need anything to make it "pass". If it does what will be the true impact on the Bitcoin network ?
It will significantly increase the transaction capacity as many recurring small payments can use the lightning network instead of having on chain transactions for all of those transactions. |
|
|
|
How do I run the salvagewallet option? I don't see it in the console as an option.
Pardon my lack of knowledge in this field but I don't know how to run pywallet either. If theres step by step instructions for the salvage wallet or pywallet options that you could give that would be greatly appreciated.
Thanks
Stop Bitcoin Core. Right click the shortcut you are using to start Bitcoin Core and choose properties. In the Target box, add -salvagewallet to the end of whatever is already in that box with a space between what is already there and -salvagewallet. Click OK. Double click the shortcut to start Bitcoin Core. Once Bitcoin Core has started, edit the shortcut again (while Bitcoin Core is still running) and remove what you just added. Pywallet has instructions for running it. You will need to use the command prompt. |
|
|
|
|
Show Posts
