Difference between originator of transaction and owner of the source fund

Here is an excerpt from Andreas Antonopoulos, Mastering Bitcoin, Chapter 5 (Transaction), sub chapter(Creating Transactions):

enter image description here

My question is what’s the difference between the originator of transaction and owner of the source fund?
Who actually signed the transaction? For example, if Alice pay to Bob 0.1BTC, is that transaction signed by Alice?

Transaction size limit across a single path in a Lightning Network and fee earned

Given MPP is included in the current version of lnd, an arbitrarily large transaction can be processed in the network. What is the transaction size limit across a single path? Is it still bounded to 0.0429 BTC (limited by max_concurrent_htlc)? What is the estimated fee earned (average as well as maximum) by a lightning node per day?

How does having a large mempool and allowing a greater transaction ancestry set change the interaction with your peers?

Bitcoin Core by default allows up to 300 MiB of mempool data, and restricts unconfirmed transaction trees to an ancestry set of at most 25 transactions and 101 kvB of transaction data. Since these are config values, you can obviously use other values than these. How does this change your node’s interaction with its peers? Do peers send data that exceeds your node’s preferences and your node drops that data upon arrival or does your node inform its peers what to send? Is this the same for mempool data generally and unconfirmed chains specifically? If you allow more data via higher values, does your node forward previously unacceptable data to its peers once their backlog clears enough for the data to be accepted by them?

How can I avoid paying transaction fees?

Is there a way to transfer/import bitcoin from one address to another in order to avoid transaction fees?

No. It is not possible to move btc between addresses without publishing a transaction to the blockchain. However, there are some ways to accomplish a similar result (transferring/altering the ability to spend some coins), but I think every one of those ways will employ a different trust model than actually transacting on the blockchain. As a user, you must balance the level of trust you are comfortable with, against the need to save on transaction fees.

Some examples:

Off chain transactions using a centralized service:

This is how an exchange moves btc between accounts without incurring transaction fees. For example, when you buy/sell on a bitcoin exchange, a transaction is not actually published to the blockchain. Rather, the exchange will simply update their internal database, which keeps a ledger of all user account balances. As a user you are trusting that the exchange has a full reserve of all outstanding user $ and btc balances, and that they will not make an error in keeping track of your account balance.

Off-chain transactions by exchange of private keys

You can give someone bitcoin by simply giving them a copy of private keys for a funded address. In this situation, the recipient will need to trust that you do not own any other copies of the private keys, or that you will not spend the coins yourself if you do have a copy saved.

(as an aside, if you are sharing keys with a friend, and the coins are stolen by a third party, it may be impossible to prove to your friend that you did not simply steal the coins- and vice versa).

Off-chain transactions by exchange of private keys, which are provably not backed up

This is made possible by specialized hardware, such as that produced by OpenDime. In this case, as long as you trust that the OpenDime hardware functions as advertised, you can give someone a funded OpenDime stick and they do not have to worry that you might have a backup of the keys for those coins.

A signed transaction that is communicated off-chain

In this case, you could sign a completely valid bitcoin transaction that sends coins to your recipients address, and then send someone the raw tx data, without publishing it to the blockchain. The recipient would be able to publish the data to the blockchain themselves, but they will have to trust you to not sign and publish a different transaction using those same outputs in the meantime. This method would also only ‘delay’ the spending of the tx fees.

(I’m honestly not aware of any actual use-case for a scheme like this. It’s probably a dumb idea that requires a lot of trust, but it is possible nonetheless)

Payment channels

In this case, two transacting parties can lock some amount of btc into a special multi-sig address, and then trade a limitless number of partially signed transactions back and forth off chain, with no tx fees, and no need to trust the other party will not steal your bitcoin. The parties involved can only exchange value up to a maximum amount (the amount they locked into the channel), but the channel can be bi-directional, so payments can be sent back and forth basically endlessly otherwise. This method still requires a transaction fee to open and close the payment channel, but that fee now account for a vast number of ‘off-chain’ transactions, instead of just one or two on-chain.

An implementation of this idea is the lightning network, it is currently live on the bitcoin testnet.


Transaction has 135 confirmations,but bitcoin not received

I sent money via bitcoin, and I have 135 confirmations already, But according to blockchain.info, 6 confirmation enough for Bitcoin transaction. mine has 135 confirmation now but still didn`t receive it. How long can it be take more to receive it? and is it possible to happen like this?

Bitcoin address are correct, but still not received after 135 confirmation.
Is it possible to not receive it in spite of this many confirmation?…

blockchain – How to find Z value of multisig transaction?

What you’re asking for is how to figure out what to sign for a multisig transaction.

Multisig is actually very close to this answer. There are a few subtle differences, however, so let me try to summarize step-by-step using the transaction as seen on the blockchain

Note that for each input, the actual hash to be signed is going to be different. Namely, you will need to fill in the redeem script for that input only and nulls for every other input. To illustrate, let’s figure out what you need to sign for the very first input.

  1. Transaction version: 01000000
  2. Number of inputs: 03
  3. Tx input #1 hash: fdb1fe0b4506f8d412f8498a0d747701bc5ed8c009e779ee670c82361c1d1dd5
  4. Tx input #1 index: 01000000
  5. Tx input #1 redeem script length: 47 (71 bytes)
  6. Tx input #1 redeem script: 522102cebf6ab580948d146b7cc771d8e646974349d3d7b11f3e03287d0997a477d3b921037ba651485b7a2cb222191eb64a55926e62bbabfe9b5ed2a9488aad547b20428252ae
  7. Tx input #1 sequence: ffffffff
  8. Tx input #2 hash: a614d26f1878078a00a3c296085576cd7e6361234ea82c865681041fcfdacea8
  9. Tx input #2 index: 01000000
  10. Tx input #2 redeem script length: 00 (nothing)
  11. Tx input #2 sequence: ffffffff
  12. Tx input #3 hash: d064d2f9cf9e5196a9d81dd87718c9cfbec97f3ccac7164946d956421597c7f1
  13. Tx input #3 index: 01000000
  14. Tx input #3 redeem script length: 00 (nothing)
  15. Tx input #3 sequence: ffffffff
  16. Number of outputs: 01000000
  17. Amount being sent to the first (and only) output: e068704600000000
  18. Output script length: 19
  19. Output script: 76a9142c76e6fdd1a81c902afa62e78ec71435708d9d9d88ac
  20. Lock time field: 00000000
  21. SIGHASH_ALL: 01000000

Now, if you double-sha256 these bytes you get:

9c4b551f37f4b383af9216045d80b2fcd4ed57bddca8df388ec29601cbd2a4f1

And indeed when you check against the embedded signature of that transaction, you can see that that is indeed the hash that was signed. Here’s a code sample to verify using the excellent btcd library written in go:

package main

import (
    "encoding/hex"
    "fmt"
    "hash"

    "github.com/btcsuite/btcec"
    "github.com/btcsuite/fastsha256"
)

// Calculate the hash of hasher over buf.
func calcHash(buf ()byte, hasher hash.Hash) ()byte {
    hasher.Write(buf)
    return hasher.Sum(nil)
}

// Hash160 calculates the hash ripemd160(sha256(b)).
func Hash256(buf ()byte) ()byte {
    return calcHash(calcHash(buf, fastsha256.New()), fastsha256.New())
}

func main() {
    x := "0100000003fdb1fe0b4506f8d412f8498a0d747701bc5ed8c009e779ee670c82361c1d1dd50100000047522102cebf6ab580948d146b7cc771d8e646974349d3d7b11f3e03287d0997a477d3b921037ba651485b7a2cb222191eb64a55926e62bbabfe9b5ed2a9488aad547b20428252aeffffffffa614d26f1878078a00a3c296085576cd7e6361234ea82c865681041fcfdacea80100000000ffffffffd064d2f9cf9e5196a9d81dd87718c9cfbec97f3ccac7164946d956421597c7f10100000000ffffffff01e0687046000000001976a9142c76e6fdd1a81c902afa62e78ec71435708d9d9d88ac0000000001000000"

    b, _ := hex.DecodeString(x)

    hash := Hash256(b)
    fmt.Printf("hash of thing to sign: %xn", hash)

    pubkeyStr := "02cebf6ab580948d146b7cc771d8e646974349d3d7b11f3e03287d0997a477d3b9"
    pubkeyStr2 := "037ba651485b7a2cb222191eb64a55926e62bbabfe9b5ed2a9488aad547b204282"
    pubkeyBytes, _ := hex.DecodeString(pubkeyStr)
    pubkeyBytes2, _ := hex.DecodeString(pubkeyStr2)

    p, _ := btcec.ParsePubKey(pubkeyBytes, btcec.S256())
    p2, _ := btcec.ParsePubKey(pubkeyBytes2, btcec.S256())

    fmt.Printf("pubkeys: %s, %sn", p, p2)

    sigStr := "3044022025332b6dabf11e493fbc62c93e7302c48666512e1cf88157c26176f4af6d064702201ee7ec25d0917244e514c402e8751f112dfd1bef2b22ec5e496fbafabb52bf010148"

    sigStr2 := "3045022100fa1f17bf59bee0ac33ae5f682711c5471c73a4aeb898aee218478289a4c7aa6e02207b40dfeae3fa4a50dc147bd42be40370d76a35d72c0b27b27c4ba2439a565fb901"

    sigBytes, _ := hex.DecodeString(sigStr)
    sigBytes2, _ := hex.DecodeString(sigStr2)

    s, _ := btcec.ParseDERSignature(sigBytes, btcec.S256())
    s2, _ := btcec.ParseDERSignature(sigBytes2, btcec.S256())

    fmt.Printf("sig: %sn", s)

    fmt.Printf("signature valid: %vn", s.Verify(hash, p))
    fmt.Printf("signature valid: %vn", s2.Verify(hash, p2))

}

You can do the same thing with input #2 and input #3 to get the hash that gets signed by changing #5 and #6 (combined) to be 00 and #10 or #14 in the steps above to be 47522102cebf6ab580948d146b7cc771d8e646974349d3d7b11f3e03287d0997a477d3b921037ba651485b7a2cb222191eb64a55926e62bbabfe9b5ed2a9488aad547b20428252ae

How to find what is suitable transaction fee to send 10 mBTC?

Using MultiBit Desktop Wallet, I can see that the default transaction fee is set to 0.5 mBTC per KB.

Usually that default rate worked fine. But yesterday, when I tried that and my transaction has not been confirmed for over 12 hours now.

So today I increased the fee to 1mBTC per KB and tried to send another 10mBTC to the same destination wallet. It is half an hour now and it has not confirmed either.

It is really frustrating. I’m wondering what is wrong here, and how can I choose a fee that make near instant transaction possible.

security – Someone made a small, apparently fraudulent, transaction to my public address. What is the purpose behind it?

I have a small e-commerce site and someone made three cryptocurrency purchases just seemingly to know my public addresses as she never paid the cost of goods. The three addresses she viewed are public derived from the master public key so there shouldn’t be any security problems there afaik.

She seemingly wanted to know my BTC, ETH and LTC addresses but only made a small transaction of $1.89 in BTC. I got 0.2ยข and other address got the rest. Here’s the blockchain transaction data.

By the multiple transactions from this address and others related to it, it looks like if someone is trying to move a large quantity of BTC through multiple addresses to make it difficult to track. But why using public addresses from e-commerce sites like mine? Shouldn’t be the same creating multiple new addresses? Maybe you can extract more meaning from this transaction and the intention behind it.

For additional info, the IP from where she made the purchases at my site is 68.65.122.134