Maand: oktober 2017

In the book “Mastering the Blockchain” by Imran Bashir, it says that a transaction’s life cycle is the following:

1. A user/sender sends a transaction using wallet software or some other interface.
2. The wallet software signs the transaction using the sender’s private key.
3. The transaction is broadcasted to the Bitcoin network using a flooding algorithm.
4. Mining nodes include this transaction in the next block to be mined.
5. Mining starts once a miner who solves the Proof of Work problem broadcasts the newly mined
   block to the network. Proof of Work is explained in detail later in this chapter.
6. The nodes verify the block and propagate the block further, and confirmation starts to generate.
7. Finally, the confirmations start to appear in the receiver’s wallet and after approximately six
   confirmations, the transaction is considered finalized and confirmed. However, six is just a
   recommended number; the transaction can be considered final even after the first confirmation.
   The key idea behind waiting for six confirmations is that the probability of double spending is
   virtually eliminated after six confirmations.

My question:

Now all nodes have competing miners to create a block by receiving all transactions by all nodes/users that submit transactions and packing it, which is not coming from one place. If we call the winner, the miner that solves the PoW problem first, then how do we know that he received all the transactions he’s supposed to receive before announcing that he created a valid block? My miner software could ignore a few transactions and get to mining earlier than others, and hence beat everyone else (assuming we all have the same computational power).

My question also can be read in a different way: How do ensure that all miners are solving the same PoW problem, while big latency times can be involved in the Bitcoin network (because we’re mining from around the world)?

According to the documentation on bitcoin.org and the Mastering Bitcoin book, you can use an extended public key to create child public keys in HD wallets by combining the lefthand side of the hash output of the parent chain code + parent public key + index:

The seemingly-random 256 bits on the lefthand side of the hash output are used as the integer value to be combined with either the parent private key or parent public key to, respectively, create either a child private key or child public key

I understand how this lefthand side output can be combined with the parent private key to generate the child private key, which in turn can be used to generate a valid child public key.

How is it possible that the child public key generated by combining the hash output with the parent public key corresponds to the child private key generated separately by combining the same hash output with the parent private key?

I thought that in was impossible to generate a public key without knowing exactly what the private key was. How is the relationship between child private and public keys (K = k*G) maintained when they are generated separately in this way?.

It was definitely on August 24th 2017, but not sure about the block number. Many sources reference block 481,822; but others state 481,824.

Also, even if this was the first block to allow segwit transactions, what was the first very block that contained one of them?

I’m with three exchanges, one says they don’t support BTG and therefore user should withdraw their BTC before Nov 16th’s fork takes place.

Another one says they will issue 1:1 segwit2x.

The last one doesn’t seem giving a clear answer.

I have some BTC in these three places. If I withdraw my BTC to my desktop wallet, would I be able to receive segwit2x and BTG when fork take place?

I think I have a general understanding of how the Lightning Network works. However, I was having a little difficulty in understanding what happens when a node in the middle of a “path” suddenly goes dormant, or offline for a long time. To clarify my question, consider the following example:

1. A wants to make a payment of 1 BTC to D.
2. A finds a path from A –> B –> C –> D.
3. D generates an R and sends H = hash(R) to A
4. A creates HTLC of 1.002 BTC with B.
5. B creates HTLC of 1.001 BTC with C.
6. C creates HTLC of 1 BTC with D.
7. D unlocks HTLC, receives 1 BTC, and then tells R to C.

However, what if C is suddenly offline meaning C won’t be there to receive R from D and thus stops the flow of R back through the path. I would assume that the HTLC’s between A and B and B and C run out and so A and B are refunded.

So, would C lose out? Would A have just made a “free” transaction? I assume this is a fast process, but is it likely such an event occurs where a middle node in an LN transaction just goes down for a long while?

Is there an easy to understand step by step guide I can execute to create a double spend and get the unconfirmed transaction reversed back into the original wallet so I can resend it with a higher fee and get it delivered?

The process is depicted in this picture. Specifically, given that the root seed was derived using PBKDF2 (with 2048 rounds of hashing with HMAC-SHA256 already), why do we undergo an additional pass of HMAC-SHA512, besides for creating 512 bits of entropy? Why not just use SHA512 alone? I’ve asked here before and the answer I got was that the HMAC version is used to ensure unique generation of the key, but I don’t know what that means. It seems for derivation of the master private key and chain node, the function is being used as a one-way hash function only, so why is a MAC being used? There is a single thing being encrypted, we are not additionally trying to guarantee authenticity on anything here, right?

If Bitcoin Gold fails to implement replay protection, will I risk losing my Bitcoin when I make a Bitcoin Gold transaction?

Assuming replay protection is not implemented properly, how can I protect myself?

So I am trying to run bitcoin daemon as a service on windows 10, so I don’t have to keep starting it.

I have tried the following command:

sc create BitcoinServer binpath= "C:\Program Files\Bitcoin\daemon\bitcoind.exe -regetest" start=auto 

Which creates a service, but when I try to start that, I get an error:

Is there any way to create a bitcoind regetest service?

Due to an upgrade, I had to recreate my wallet (vault) file from scratch – a process that took over a week. During this time, I was able to spend one coin (sending it to blockchain.info) because I somehow managed to find an old copy of the software and it worked for one transaction only and then fell over. That appeared to work fine. When looking at the ‘watch only’ address imported into my blockchain.info wallet, it showed the spend plus the remainder at that address being sent to another address starting with ‘3’. I was comfortable with this because mSigna wallet addresses start with ‘3’ because they can be multi-sig wallets. However, when mSigna finally completed syncing my new vault file, the unspent coin actually shows up in my list of wallet transactions as ‘spent’. Obviously this is a shock to the system – it’s quite a bit of coin.

However, I think what happened is that the address of the unspent output is somehow not in sync with my wallet and that’s why I’m showing a balance below that which I should truly have.

I can think of two possible paths forward:

1. If I can get the private key from mSigna, I can move the funds manually through a site like blockchain.info, or

2. I try to re-sync the entire wallet again – and wait a week or more

Are there any other ideas worth considering? Thanks in advance for your help.

Jim