text:
Restore android wallet on a mac
Ok, so I have this bitcoin wallet backup.

I have the 12 word seed
I have a password
I have a number in this format ****/** that I wrote down.

I made this backup on an android tablet. Not sure which app. I think "Bitcoin Wallet", which is android only, apparently.
I obviously would like to restore it, but I don't own anything android anymore. Any way I can do this on any Mac/iOS app?

I tried putting my backup in Electrum's wallet folder, with no success.
I tried decrypting it as described here. Not sure what I'm supposed to do with the "decrypted" file that is as unreadable as the original.

help.
Update : I tried restoring with Multibit, which I read was compatible with Android Bitcoin Wallet because bitcoinj. Multibit accepted my seed and the ****/** number as a timestamp, did not recognize the backup file (which according to MB docs is not a big deal) and went on an all-night journey to 'sync' with the network.
In the morning I had a new wallet with 0 bitcoins in it.
Does this mean my wallet was empty all along? That I'm using the wrong seed? That I just need to find an old Android phone to try again?

This is what I would do:

Find/borrow an android device (from a friend, relative, co-worker, etc)
Install the Bitcoin software you used to have
Restore the wallet from the seed (when restoring from a seed, in most cases the password isn't needed, because you can set a new password after the restoration of the seed)
Make a new transaction and transfer all bitcoins to the new wallet address on iOS/OSx

Caution! The seed is the most important thing you have. Don't show/give the seed to anyone because they can recreate the wallet!


text:
Bitcoin qt client opening and immediately closing
I'm trying to run a bitcoin-qt client (to sync blockchain) on a raspberryPi (using Raspbian Stretch With Desktop). However, the bitcoin-qt client opens and just closes. BTW db.log is empty. Here is (tail) of my debug.log (in which atl i don't spot any errors).
2018-07-18 16:31:09 Bitcoin version v0.13.1.0-g03422e5
2018-07-18 16:31:09 InitParameterInteraction: parameter interaction: -whitelistforcerelay=1 -> setting -whitelistrelay=1
2018-07-18 16:31:10 Default data directory /home/pi/.bitcoin
2018-07-18 16:31:10 Using data directory /mnt/usbstorage/.bitcoin
2018-07-18 16:31:10 Using config file /mnt/usbstorage/.bitcoin/bitcoin.conf
2018-07-18 16:31:10 Using at most 125 connections (1024 file descriptors available)
2018-07-18 16:31:10 Using 4 threads for script verification
2018-07-18 16:31:10 Using BerkeleyDB version Berkeley DB 5.3.28: (September  9, 2013)
2018-07-18 16:31:10 scheduler thread start
2018-07-18 16:31:10 Using wallet wallet.dat
2018-07-18 16:31:10 init message: Verifying wallet...
2018-07-18 16:31:10 CDBEnv::Open: LogDir=/mnt/usbstorage/.bitcoin/database ErrorFile=/mnt/usbstorage/.bitcoin/db.log
2018-07-18 16:31:10 Bound to [::]:8333
2018-07-18 16:31:10 Bound to 0.0.0.0:8333
2018-07-18 16:31:10 Cache configuration:
2018-07-18 16:31:10 * Using 2.0MiB for block index database
2018-07-18 16:31:10 * Using 8.0MiB for chain state database
2018-07-18 16:31:10 * Using 290.0MiB for in-memory UTXO set
2018-07-18 16:31:10 init message: Loading block index...
2018-07-18 16:31:10 Opening LevelDB in /mnt/usbstorage/.bitcoin/blocks/index
2018-07-18 16:31:10 Opened LevelDB successfully
2018-07-18 16:31:10 Using obfuscation key for /mnt/usbstorage/.bitcoin/blocks/index: 0000000000000000
2018-07-18 16:31:10 Opening LevelDB in /mnt/usbstorage/.bitcoin/chainstate
2018-07-18 16:31:10 Opened LevelDB successfully
2018-07-18 16:31:10 Using obfuscation key for /mnt/usbstorage/.bitcoin/chainstate: 68657831113e179

Any idea what might be going on. My next solution is to simply delete the .bitcoin directory and start afresh.
[EDIT]
I think its important to mention that it did startup once and it was synching. Then for some reason my pi shutdown so i coudln't close it in a graceful way i guess. That could be the issue. In anycase, wanted to know if there was a way to start synching from where i left off.

Looks alright. Does /mnt/usbstorage/.bitcoin/db.log have any errors?

The db.log is empty.

How did you install bitcoin-qt on a raspberry pi? AFAIK, there is no bitcoin-qt binary for ARM devices yet.

Well, i just used apt-get to download bitcoin-qt and bitcoind and ran bitcoin-qt.

Try running it from a terminal so you can see any messages generated; in particular, if it's getting a signal, you'll see a message.  Also check your system logs (maybe /var/log/syslog).  How much RAM does this device have, and how much swap if any?

Also, v0.13.1 is very old, and I don't think you'll be able to use it successfully with the current network.  So you're eventually going to have to find or compile a more recent binary.

Good point @NateEldredge , i will try to find a newer version and probably restart the whole process. Thanks.

Note that if you don't have at least 2 GB of RAM, it's probably a lost cause.

I believe default is 1GB. I have not added any more. Do you think that will be an issue?

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

sort: votes


text:
Correct way to implement bitcoin:<address> URI handling in Gnome desktop
I run bitcoin-qt all the time, so I set the browser to handle bitcoin: URI with bitcoin-qt.
Unfortunately that causes a new instance to be started, which fails coz it fails to get a lock on the database.
What's the best way to do this?
I have 'server=1' to enable json-rpc access to bitcoin-qt.
Do I need to set the browser to handle these links with (say) bitcoin-cli?
Or do I need to reconfigure the whole thing and run bitcoind as well?

I've duplicated the question on askubuntu as well: https://askubuntu.com/questions/1383898/bitcoin-uri-handling

My question isn't about general URI handling tho. It's only bitcoin that I have the problem with.
Even a mp4 link works when (say) vlc is already running. There's no issue with locking of course, but vlc has an option to run a new instance or start the video in the existing instance.
That's why I'm here. It's very bitcoin specific, but I feel sure there's a 'best' way to handle it.

Ouch! That's what I want.
What is that '-W1' in the title? Is that relevant?
Mine is v22.0.0

Just to confirm: you had bitcoin-qt already running when you clicked that link?

Maybe my desktop file is bad. Does this look like yours?
[Desktop Entry]
Type=Application
Name=Bitcoin
Icon=/home/xxx/.local/share/icons/bitcoin.svg
Exec=/usr/bin/bitcoin-qt -min -testnet=0 -regtest=0
Terminal=false
Hidden=false

Thanks for your time btw. This is looking like a bad configuration on my end somehow.

OK. I got it working! It needed a parameter (%U) in the exec line of the desktop file.

For anyone else trying this, note that the BIP-21 bitcoin wiki page (https://en.bitcoin.it/wiki/BIP_0021) examples of bitcoin: links don't work. They are invalid addresses now for some reason. I needed to get a link from bitrefill to get this thing to behave.

The simple answer is that when the parameter '%U' is missing from the 'Exec' line in a gnome/Ubuntu desktop file, the OS creates a new instance whenever the application is called (in this case by the browser on clicking a bitcoin: link on a web page). That fails when the application can only have one instance running (bitcoin-qt by itself handles the bitcoin database; no other app/instance can be simultaneously doing this).
The 'magic' is that when the '%U' parameter is present, the OS sends the request to the running app and, in this case, that appears as a bitcoin transaction in bitcoin-qt as expected.
Over the years of playing with bitcoin.desktop, i had managed to lose that parameter somehow. Very confusing.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
2 mBTC that was outputted as change in a transaction I just sent didn't come back to my wallet
Hi I'm new to this so may be asking a stupid question.
I just sent a payment for 198.52 mBTC. There were two outputs. One for 196.39 mBTC that arrived. There was another output of 2 mBTC that didn't arrive and wasn't refunded to the first wallet. I looked on google and I read that the 2 mBTC was change for the transaction. Can somebody tell me how I retrieve this 2 mBTC as it's not in my wallet?
Many thanks

Possible duplicate of How does change work in a bitcoin transaction?

You don't need to retrieve it.
Your own wallet created that output, and sent it back to a different address under its own control. Your wallet's balance should reflect this change.

Thanks for getting back to me. The issue is that my wallets balance does not reflect this change. The recipient has 196.39 mBTC and I have a balance of zero. the 2 mBTC has disappeared.

Also I just checked my addresses (receiving and change) and the address the change was outputted to isn't in the list.

What wallet software?

I am using Electrum on my Mac.

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
Why is it harder to compute nonce for a hash with a certain number zero prefixes than it is for any other hash?
Based on my rudimentary understanding of Bitcoins and altcoins, network difficulty is adjusted by asking the network to target a hash smaller than a specific number, which translates to calculating nonce for a hash with a certain number of zeros prefixed to it.
Since hash values are supposed to be uniformly distributed, I don't understand why targeting a hash value with a specific number of zeroes is any more easy/difficult than targeting any other hash (not the hash value of the content without nonce obviously). I think targeting any of the possible hash values, except what the content already hashes to, should be equally difficult. Why is that not the case?
It's very likely that my understanding of Bitcoin network difficulty itself is wrong, in which case, could you please explain that to me?

Why do you think it's harder to look for hashes with a certain number of leading 0s than it is to find hashes that start with, say, a7e741e671d7401bfd4?

Actually, I don't think it should be any harder to look for hashes starting with a certain number of leading zeroes than it is to look for any other hash. But the Bitcoin/altcoin network difficulty settings seem to work that way. It's possible I'm misunderstanding how Bitcoin network difficulty works, which is why I asked this question.

A hash is 256 bits long, so there are 2^256 possible hashes in the hash space. But if you assert that the hash has to begin with a 0, that halves the number of hashes that are allowed (and thus doubles the average number of hashes you need to test), and if you say it must start with two 0's, that's now only quarter of the hash space that is valid. The difficulty of finding a valid hash thus grows exponentially with the number of 0's you require at the start.
But as you said, because the hashes are uniformly distributed, there is nothing unique about requiring the hash start with x number of 0's. Requiring the hash to start with x number of 1's would be the same, as would any specific sequence of 1's and 0's be. 0's are just a nice choice and make sense in practice, because like you said, you are then computing a hash less than a specific number.
Just to point out the terminology difference by the way, it's not targeting a specific hash, it's targeting a specific subset of the possible hashes. To find a specific hash would mean SHA-256 is broken, because you are basically reversing the hashing operation.

Thanks for the explanation. Realizing that there's a whole set of acceptable hash values for the problem as specified by the difficulty number clarified this for me. :)

Finding a hash that is less than the target requires more work (not harder, there is nothing that makes hashing harder to do), i.e. more hashes. This is because there are more numbers with more digits (and thus larger) than there are with less digits. For example, there are 90 numbers with 2 digits, compared to only 10 with 1 digit. This is an exponential distribution. Because of this distribution, more work is required as the target is made smaller because you are significantly reducing the set of all possible valid hashes.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
Wouldn't bitcoin benefit from distributing partial blockchains over each node?
Why doesn't each node store only a portion of the blockchain?
For example, if you had 100 nodes, each node would store 10% of the blockchain. This would amount to significant overlap of each aspect of the blockchain, and as nodes came and left there would be increased or decreased sharing of the blockchain.
Is it infeasible? If so, why? I am interested in pursuing this as a project because I think it could solve a lot of bitcoin's scalability/decentralization issues.
From my understanding of the blockchain, let's assume a particular node starts at the genesis block. Let's assume another node stores 1% of the blockchain past the genesis block. Couldn't multiple node verify block hashes for their shared 9% at a rate of once every 10 minutes? It wouldn't really use that much data -- you could hash the 9% of the blockchain to a particular value, produce a public key, and see if the other nodes can match a private key to said public key.
A related question: Is this what Electrum does? Or, does Electrum simply store the entire blockchain on multiple servers that you can connect to?

Why doesn't each node store only a portion of the blockchain?

This has been proposed before and is possible with Bitcoin, but it's not clear how it would be executed. The blocks aren't an important part of a running node, for most people you can throw them out as soon as you have processed them into your UTXO database.
The problem comes when deciding which parts to store, and signalling to other people in the network that you have a certain subset of blocks. You can't advertise a list of hashes as that would be massive and inefficient (many megabytes for each peer), and making a deterministic random selection is extremely problematic. Choosing ranges of blocks is not ideal because the sizes are not consistent, 1,000 blocks at the beginning of the chain is servers orders of magnitude smaller than ones at the tip. In a naive implementation of random selections peers attempting to sync with the network may need to make thousands of connections to find a single peer that has a specific block, which is obviously not feasible.

From my understanding of the blockchain, let's assume a particular node starts at the genesis block. Let's assume another node stores 1% of the blockchain past the genesis block. Couldn't multiple node verify block hashes for their shared 9% at a rate of once every 10 minutes? It wouldn't really use that much data -- you could hash the 9% of the blockchain to a particular value, produce a public key, and see if the other nodes can match a private key to said public key.

This is not necessary and highly vulnerable to Sybil attacks, you don't need to verify blocks once you have seen them. Pruned nodes work like this today, only they throw away every block and store absolutely nothing more than they are specified to sore. They don't advertise which blocks they have because there is no mechanism for that.
You might want to read up on how the autoprune patch works and get a better grasp on the threat models that need to be tackled here. You've missed some of the operation slightly, note that pruning for nodes nodes does not operate in the way described in the white paper, the UTXO is a newish concept added in 0.8.0 era Bitcoin Core.

A related question: Is this what Electrum does?

Not at all, Electrum servers are a full node and an extremely heavy address based index, almost doubling the storage size. The client is light weight but the sever most definitely is not. There's no sensible way of maintaining these indexes in a sharded way, though you could break addresses into multiple pools and hope that people maintained enough of each shard for clients to be able to request subscriptions for all of their addresses. Ideally systems would be designed that don't require full indexes as they are getting increasingly unwieldy to work with.

"The problem" - I don't think that's really a problem as much as simply a design choice that hasn't been made yet. You could easily split the blockchain up into approximate 50-100MB chunks and identify them by hashing the entire chunk.

That’s not verifying, you need to be sure there’s not something invalid in the rest of the information.

Right, well I wasn't talking about verifying. I was talking about sharing information about what parts of the blockchain you have on-hand. In response to your second paragraph

I think I may not quite be responding in the full context of the OP.

Something like this has been implemented and released in v0.11.0 in Bitcoin Core client.  Its called pruning and you can now use the -prune option specify how much blockchain data you want to store.
-prune=N: where N is the number of MB to allot for raw block & undo data

This does not work as yet in terms of wallet so when pruning you cannot use the wallet in the core client.  It's also stops relaying though they are working on ways to incorporate that to allow nodes to still relay blocks.
This does not mean that nodes store different part of the blockchain though.
Note that a new node in pruning mode will still download and work its way through all blocks, but will not keep all old blocks.
It's my understanding that this will be updated to support using the wallet in pruning mode in future. EDIT: Apparently master branch of bitcoin core already supports using the wallet in pruning mode.

Master at least supports a wallet and basic pruned mode.

This answer isn't correct. Pruning is about forgetting old, irrelevant data, and has been described as early as the whitepaper. The question asked about sharing the load of the relevant data between different nodes, which would require significant algorithmic innovations.

@MeniRosenfeld Worthwhile to note that the client modes described in the whitepaper don't really function like that at all in the real world, I'm not convinced it's a thing to be pointing people to that information anymore.


text:
How to encode a string into a bitcoin address? (Not a brain-wallet, an address, like a vanity-address)
I would like to know if a bitcoin burn address can be tied to a string. This question is not about OP_RETURN or other ways of embedding into a blockchain.
Here's the processes that I went through:

Create a 21-byte string (aaaaaaaaaaaaaaaaaaaaa)
Convert this string to hex here: http://string-functions.com/string-hex.aspx. I get: 616161616161616161616161616161616161616161
Take the SHA256 of it here twice: http://extranet.cryptomathic.com/hashcalc/index Get the first four bytes: 7df8e299
Now I have a hex string: 7df8e299616161616161616161616161616161616161616161. I convert it using a hex to base58 encoder: https://incoherency.co.uk/base58/
Finally I get this string: sgwP7Xqw3GWATXNF9TW3RyDG16vbzTgRHA. Which I plug into the bitcoin address cheker: http://lenschulwitz.com/base58.
The error that I get is Invalid Bitcoin address! Bad SHA-256 checksum!

Where did I go wrong?

May I ask why you would want to do this? You can have an address that commits to a string without burning money.

Sure Pieter big fan of your work. Omni transactions take up the OP_RETURN call. So if you want a cross-platform proof-of-burn token, that also puts data into the chain, you have to add tx outputs to stringified addresses.

Nick, creating unspendable outputs is harmful to the Bitcoin system because it perpetually burdens nodes to carry around state relating to these coins, you should avoid doing this. If you adopt practices like this commercially and at scale, over the long run it may cause Bitcoin users to adopt countermeasures that block your activity. (and this sort of thing is eminently blockable at the cost of making addresses quite a big longer)

I will try and do it with only 0 Satoshi outputs (as part of a larger tx with more outputs).  This should protect the UTXO pool. Nodes should not be holding 0 Satoshi outputs for any reason whatsoever. As far as blockchain "bloat" goes, I'm paying the fee for permanent graffiti, and it won't be very many transactions.

@nick carraway: spending 0-value outputs is legal. Full nodes have no choice but to keep such outputs in their UTXO set.

Aight well then i can try and create a new address version number for burning (to label the addresses used by my protocol) but i dont know if a node will accept it. If nodes start banning my non compliant version numbers i will just disguise them as traditional addresses.

@PieterWuille, you mentioned that spending 0-value outputs is legal, which is true. But generating 0-value outputs is not allowed through Core?

@nickcarraway The consensus rules allow it. There are policies around the creation of dust limits, but those don't alleviate the need to keep such outputs around if they're created in a block, as validity of future blocks may depend on them.

I had a couple errors. The first byte of aaaaaaaaaaaaaaaaaaaaa should be a version number, which can be 0. 0aaaaaaaaaaaaaaaaaaaa. The hash is appended to the end of the string, not the beginning.

Select a version number: 0
Append a 20-byte string (0aaaabbbbccccddddeeee)
Convert the 21-byte string to hex: 306161616162626262636363636464646465656565
Using a hex-compatible SHA256 (like in the link above), hash the hex string from 3 twice, then take the first 4 bytes. 27ac3662 (in hex, 2 letters = 1 byte)
Append those 4 bytes to END of the 21-byte hex string:  30616161616262626263636363646464646565656527ac3662
Convert the hex to base58 using an encoder: LU6rTvpr7C1AEpQLGwJP5xq7FBthTXAAqw.
Check in the bitcoin validator link above. should be working.


text:
Does the .bitcoin directory shrink in bitcoin-qt 0.7.2 and later?
The bitcointalk.org thread "Ultraprune merged in mainline" implies that a more efficient way of storing block information was introduced. Will this make the .bitcoin directory smaller after an upgrade to 0.7.2?

The code referred to by that thread will become 0.8, and is not in any released versions as of January 2012. 0.7.2 is a minor upgrade to 0.7.1 only, with only bug fixes.
0.8 will indeed use a more efficient storage mechanism, which will most likely result in slightly reduced storage requirements (though you may need to delete the old database manually). The most important improvement, however, should be block validation speed, and the amount of I/O to disk necessary.
In the future, the new database scheme may lead to a version that supports block pruning, where not (all) history blocks are stored on disk anymore without compromising security (it would still require downloading those blocks in full, however). Because of the invasive effects on the network if suddenly many nodes weren't able to serve history anymore, this may need some discussion first, and isn't implemented yet.

Thank you! Any numbers yet from testing of old-vs-new of the magnitude of 'slightly reduced storage requirements' for the same block chain depth? 2%? 20%?

Something like 10%, I think (don't have precise numbers).


text:
How does this OpenCL BTC private-key cracker work? Is it a real threat to bitcoins?
I am specifically referring to this over at bitcointalk.org.
The general consensus I gathered from reading the thread is that this is not a hoax. There seems to be a group of generated bitcoin addresses that can be considered weak where its private key can be recovered in a reasonable amount of time. There's currently no known way to determine if a given btc address is weak or not.
What is not clear to be me is how it is able to accomplish this. What is the basic idea behind this attack that allows it to even work? Explain it to me like I was 5, if possible. Is this is a potential break of the ECC algorithm?

The argument that those keys are weak is flawed. A particular search algorithm happens to search those keys first, thus allowing it to break those keys more quickly. But if people stop using those keys because they are "weak", then the search algorithm will just start elsewhere, making those keys stronger and other keys weaker. If you avoid weak keys, then someone trying to break your key need not search any weak keys, making everyone's keys less secure. (ECDSA has no weak keys of the type that's actually weak unless your RNG is broken.)

I hope this post by Greg Maxwell is convincing enough: https://bitcointalk.org/index.php?topic=421842.msg4809012#msg4809012
Unless your private key is generated by a weak random number generator, there is no need to worry. It effectively takes around 10^42 operations to crack a 256-bit elliptic curve private key.
He's using names of some well-known algorithms for solving the discrete logarithm problem (which is what you must do to find the private key from a public key in our case). They are significantly faster than a brute force search, but cannot break the limit posted above.
The explanation seems to boil down to "we pick some keys to start with, and if yours is close to any of them, we'll find it quickly". That shouldn't surprise anyone. The odds of being "close" to any of the keys someone chooses to start with are astronomically small however. Even being able to try millions or billions of keys per second will not change that.

Whilst I am not an crypto expert, I guess, in some programs that generate "wallet" keys (official or not), there may be a problem with the random number source that is used to create the keys (biased towards some numbers maybe). That will allow the attacker to create a link between target X variable (pub. key, user id, time created, or whatever, I don't know...) and private key. Naturally, it would reduce the amount of possible private keys to a reasonable amount and let it be cracked.
Wallet system is asymmetric cryptography after all and this is the only reason I can think of. Further reading on wiki on asymmetric cryptography.


text:
Do pool operators usually set block version numbers before their clients hash?
I know that pool operators have the power to modify the actual transactions in a block. I also know that pool operators can decide on block transaction orderings and even commit double spends pretty easily.  I know that pool operators send the merkle root hash of this block to miners. The miner then provides the nonce, which is the hard work of mining.
But, there's another part to mining, which is the block version number. Do most pool operators set this, for e.g. voting, and which bits are able to be set for votes?

I know that pool operators have the power to modify the actual blocks inside a transaction.

Transactions don't contain blocks. Miners/pool operators can't modify any of the normal transactions inside of a block. They can only change things in the block header, the coinbase transaction, and the transaction ordering.

I also know that pool operators can decide on block transaction orderings and even commit double spends pretty easily. I know that pool operators send the merkle root hash of this block to miners. The miner then provides the nonce, which is the hard work of mining.

Not necessarily. It depends on the protocol being used. If it is stratum, this is largely true (except the merkle root thing. Stratum only provides part of the merkle tree for the merkle root so that an extranonce in the coinbase can be used.)
If getblocktemplate is used, the miner has a lot of control over what is being hashed. With GBT, instead of just part of the header and hashed data being sent to the miner, the entire block structure is sent and the miner constructs the block and block header himself before hashing it. This means that the miner could choose to change whatever he wants in the block.

But, there's another part to mining, which is the block version number. Do most pool operators set this, for e.g. voting, and which bits are able to be set for votes?

If the pool is using stratum without ASICBOOST support, then the pool operator sets the bits for the miner. If ASICBOOST is supported, the miner can modify some of the bits in the version number in order to use ASICBOOST. With GBT, the miner can modify the version number if the pool indicates that they will accept a block with a version number different from the one that they set in the block template.
Also, note that miners do not vote. Setting the version number for soft forks is not a vote, it is signalling that the miner is prepared to enforce the rules of a soft fork. It is a signal of readiness, not a vote.

LOL sorry, I meant transactions inside a block. The entire post was written from a very tired brain. Also, version numbers can be interpreted as a vote.

But they aren't used as one? It seems the coinbase parameter is the primary way to vote: https://bitcoin.stackexchange.com/questions/50446/what-are-the-possible-version-bits-votes


text:
Verifying a digital signature that a transaction is going to an output with value X inside a script
Edit; after writing this post i have found that OP_CHECKDATASIG is basically this in a nutshell. It is implemented on Bitcoin Cash and may soon be on Bitcoin Core as well.
Someone has even written this post into a Bitcoin Cash smart contract: https://honest.cash/pein_sama/spending-constraints-with-op_checkdatasig-172

Yes, this is possible in the Bitcoin Cash blockchain only. It would also be possible in OP_CODES, but much harder.
Here's how it works:
In the script signature, we check both OP_CHECKSIG and OP_CHECKDATASIG. First, OP_CHECKSIG goes "outside" and checks that the signature validates the transaction outputs. Thus, the signature variable has now been externally-verified to contain information from the transaction outputs.
In OP_CHECKDATASIG, we then verify that an input variable called "preimage" is the precursor to this exact "signature". Since digital signatures are unique, this pre-image must be the transaction itself. So, we now have a variable called preimage, that, transitively, is externally-verified to the transaction outputs. Coincidentally, this is also the raw transaction data containing the outputs.
Finally, we step through the preimage to determine the contents of the transaction before allowing spending. Very cool. (edited)

but in bitcoin usually the message is a hash of the previous transaction and the 'to' pubkey-hash and/or transaction? Unless i am missing something, the SIGHASH_SINGLE parameter specifically signs only the input and output of the new transaction. So, if you could create this input and output, and sign it inside an OP_CODE with a privatekey, you could verify that an output was going to a particular person inside a bitcoin script sig. Of course, the private key holding that UTXO would be unusable except for returning BTC to the user, or perhaps another pubkey could be used to spend the UTXO.

This is incorrect. Transaction signing works by:
for every input i in inputs:
    Start with a transaction skeleton that matches the transaction for non-input/output fields like tx version
    Add the input i
    Add other inputs and outputs based on the sighash flag
    Hash this update tx skeleton
    Sign the hash

The SIGHASH flags simplify specify which inputs and outputs are covered by the signature. For SIGHASH_ALL, the entire input and output set is signed. For SIGHASH_SINGLE, only the output corresponding to the index of the input is signed (for the first input in a tx, the first output will be signed). You also have additional options such as ANYONE_CAN_PAY which allow addition inputs to be added later, by only signing your input (for use with coinjoins).
By using SIGHASH_ALL | SIGHASH_ANYONECANPAY or SIGHASH_SINGLE | SIGHASH_ANYONECANPAY flags, if you already control an output, you can specify something such as:
If this output is used as an input, at least X BTC must be sent to {these|this} new output(s).

However, this restriction only applies if the final transaction uses this specific signed input - nothing prevents you from creating another signed tx that spends that same output to a different destination and broadcasting it first.
Your example fails since within the signature, you have no information about the output. The data that is signed is that of an augmented tx skeleton as a whole - you cannot use Bitcoin Script to inspect a subset of that data and validate the signature.
To take the example another way, let us say we construct a bitcoin script equivalent to:
Accept a signature and a public key
Verify that the signature is over the data (input,hash160(public_key)
Verify the signature is performed by the same key that unlocks the input being spent

This would seem to imply that we can sign the destination public key using the same private key that owns the input, and then have a script that validates both the tx signature, and the signature over the public key we claim to send to.
However, in this case, nothing prevents you from feeding a valid signature and destination public key to the script, but specifying a completely different output in the actual tx - This is because there is simply no way for the Bitcoin Script program to read and check where the tx output(s) are actually going.

Wait, really? I can sign a group of inputs, and a group of outputs. Where the inputs provides only 0.1 BTC from my accounts. And the outputs provide 10.0 BTC as output. (invalid tx) And If i sign it with "SIGHASH_ALL | SIGHASH_ANYONE_CAN_PAY", then the transaction will go through if someone adds inputs totaling 9.9 BTC? (And I understand that it would only apply to this signed input; I could rebroadcast if i wanted)

Or can you still only sign valid TX like this?

Yes, that's correct. You can construct a partial tx, with insufficient inputs or outputs and wait for other people to complete it. I wrote a blog post on this some time ago with more detail/examples, if you are interested: http://raghavsood.com/blog/2018/06/10/bitcoin-signature-types-sighash

Thanks. I have been studying your blog post. It seems if I want people to be able to add outputs, the SIGHASH_SINGLE is the only way to do it. But this limits to a single output.  I wish that I could sign multiple outputs and still have someone else add outputs.

You can, in a round about way. If you own n utxos, you can create a tx with n inputs, each signed with SIGHASH_SINGLE for their corresponding output (1 through n). Then, anyone else can add more outputs after the fifth one

But wouldn't someone be able to degroup these transactions? I need to ensure that if one utxo is broadcasted, so is the other

Please see: https://bitcoin.stackexchange.com/questions/85732/is-there-anyway-to-sign-a-pair-of-inputs-and-outputs-and-still-add-to-the-output

This is exact stack exchange post is implemented in bitcoin cash https://honest.cash/pein_sama/spending-constraints-with-op_checkdatasig-172

But I think your explanation still holds

@nickcarraway OP_CHECKDATASIG is not available in Bitcoin, from what I recall. You might be able to use it on one of the forks, though.

I think it's coming to lightning. Also, doesn't your explanation still hold? It's still just an unlocking script that takes information from the input stack and unlocks the coin. Just want to be sure

Someone could still provide a fake signature that says the coins are going one place, where in the actual transaction they are going to the wrong place right?

????????????????

are you alive sir


text:
Is SIGHASH_NONE encompassing of other signature types?
Say I am building a transaction in private:

Input 1 is signed with SIGHASH_SINGLE  ( | SIGHASH_ANYONECANPAY)
Input 2 is signed with SIGHASH_NONE | SIGHASH_ANYONECANPAY

SIGHASH_NONE implies that Input 2 will only spend if Input 1 is included in the transaction. Am I able to communicate this privately-signed transaction in such a way that Input 1 is also locked on the condition that Input 2 is included?
For example, I send this partially-signed transaction, with both signatures, to a person I do not trust.
Are they able to spend Input 1 (the SIGHASH_SINGLE) in another transaction without Input 2 included?
What can I do to lock these two inputs together, with one of the inputs also being locked to an output, while still allowing people to add inputs to the transaction?

SIGHASH_NONE implies that Input 2 will only spend if Input 1 is included in the transaction.

This is false.
Input 2 is essentially a blank check. SIGHASH_NONE signs none of the outputs (I don't care where the BTC goes), and SIGHASH_ANYONECANPAY signs only input 2 (I don't care who else is participating in the tx. This essentially creates an input, which if you give to anyone else, is the equivalent of "Here's a blank check for X BTC, do what you want with it".

Are they able to spend Input 1 (the SIGHASH_SINGLE) in another transaction without Input 2 included?

Since Input 1 is signed using SIGHASH_SINGLE, only output 1 is signed under it. However, the SIGHASH_ANYONECANPAY flag means that only input 1 is signed as well, which completely decouples it from input 2.
Now, if you were to remove the SIGHASH_ANYONECANPAY flag from input 1, then you end up with a tx that is able to spend up to input 1 + input 2 BTC, but is only spending output 1. In this scenario, spending input 1 is dependent on spending input 2 as well. However, since input 1 is SIGHASH_SINGLE, and input 2 is SIGHASH_NONE, anyone you share the tx with is able to add their own outputs to it, but not add any more inputs.
Moreover, since input 2 is SIGHASH_NONE | SIGHASH_ANYONECANPAY, anyone you share the tx with can extract just input 2, and reuse it in a completely different tx without requiring input 1. The way to counter that would be to remove the SIGHASH_ANYONECANPAY , so that it is at least locked to being spent with, and only with, input 1.

What can I do to lock these two inputs together, with one of the inputs also being locked to an output, while still allowing people to add inputs to the transaction?

You could spend to to a single output, then create a new partial tx with that single output being spent with your required destination and amount, and sign that with SIGHASH_SINGLE | SIGHASH_ANYONECANPAY


text:
How does a full node benefit from receiving a block with a version number in its header?
Block headers are special because they're synced by SPV wallets. They're also part of the mining algorithm used by miners, which can enable controversial things like ASIC boost.
However, in the case of Segwit, the block version number was chosen to indicate the Segwit softfork. What was the advantage of including this value in the block header's version number field as opposed to in the coinbase transaction?
To be specific, does the Segwit soft fork affect the work done by SPV wallets or by ASICs, other than preventing ASICBoost in the latter case?
If the Segwit soft fork was put in the version number because "thats what version numbers are for" and "ASIC boost is bad", I'm okay with that being the reason. I even consider that a technical reason -- there may be a future soft fork that affects SPV wallets that those verison numbers are needed for, and putting the Segwit value in the block header helps protects those values (as opposed to sacrificing them to ASICboost). I'm just trying to understand what kind of soft forks might affect SPV wallets, or if I'm missing anything else.
I thought Segwit was about transaction ordering in the actual block, which could indicate the Merkle Root part of the header should be processed differently by full nodes. But if the full block is being received anyway, with the coinbase, why couldn't the segwit indicator just be put in the coinbase? (Aside from protecting those values)
I would just like to know whether I'm missing anything here. Other than protecting those values for future forks, does Segwit require any special consideration by SPV wallets / miners?  Is there any reason why the coinbase transaction couldn't be used for this particular soft fork other than future technical developments?

The block version number has traditionally been the way for miners to signal their readiness to enforce a soft fork. The version number was likely used because of its historical use for soft fork signalling. Also, the version number does not indicate that a particular set of rules are active for a block. In fact, the version bit used by Segwit is no longer set by miners (besides those using ASICBOOST) since Segwit has activated.
Additionally, the version number helps SPV wallets know when segwit is active so that they can use it. Otherwise SPV wallets would have to download entire blocks in order to examine the Coinbase transaction in order to do so, which would largely defeat their primary benefit.
Full nodes don't really benefit from the version number being used as the signal. However when deploying any kind of fork, consideration must be made for everyone in the ecosystem. Using the version number does not hurt full nodes, has some extra benefits of not taking up block space for transactions themselves, and lest SPV wallets know when the fork activates.

I thought Segwit was about transaction ordering in the actual block

No. Segwit does not effect transaction ordering at all. It changes the format of transactions and how certain output scripts are validated.

Other than protecting those values for future forks, does Segwit require any special consideration by SPV wallets / miners?

Yes. SPV wallets need to know when Segwit activated so that they know when they can make and accept transactions containing Segwit inputs and outputs.

Yea I forgot that SPV wallets' outgoing data might be improved by this header. I was only thinking about the incoming sync


text:
Problem with sendrawtransaction
When I use bitcoin-cli sendrawtransaction and only get -25 errors. I have tried to push the transaction using different blockchain explorer sites, but that didn't work. I have tried:
0100000001659d0ebe45e4446113776807a0160ab487a56f8386405e07d8d15275f18bb832010000006b483045022100e642093c9a56c76aeae91c68c19fd3f5f487d9d63c4f07259c5899a4df6f9bdf02203228b7f33a662fd5f3dc6fb3c361169392f91f74fe82ada1ce09bae55720ece70121029e033dda03e6cf9e0c93ac5b2689d047fd8e559ea0b5cfd1c86062387c672dcdffffffff0180d1f008000000001976a91476d2d121a1bbbc7e4c51f7a7c84437bb3aa1d66d88ac00000000
at
https://live.blockcypher.com/btc-testnet/pushtx/
it decodes well, I get the message  "Transaction Successfully Broadcst"
but at the same time:
" No transaction found with the hash 7f1aa3a20163a9d4058940dd6af29b3f7aefc037b2f3b21133a1413a990bc4e7"
I can send transactions using sendtoaddress and this seems equivalent. I started from:
https://live.blockcypher.com/btc-testnet/tx/32b88bf17552d1d8075e4086836fa587b40a16a0076877136144e445be0e9d65/
used:
bitcoin-cli createrawtransaction '[{"txid": "32b88bf17552d1d8075e4086836fa587b40a16a0076877136144e445be0e9d65", "vout": 1}]' '{"mrMEaWKfkJZcAN52VqNxKkF21uvf9HF9G7":1.5}'
0100000001659d0ebe45e4446113776807a0160ab487a56f8386405e07d8d15275f18bb8320100000000ffffffff0180d1f008000000001976a91476d2d121a1bbbc7e4c51f7a7c84437bb3aa1d66d88ac00000000
bitcoin-cli signrawtransaction 0100000001659d0ebe45e4446113776807a0160ab487a56f8386405e07d8d15275f18bb8320100000000ffffffff0180d1f008000000001976a91476d2d121a1bbbc7e4c51f7a7c84437bb3aa1d66d88ac00000000
{
    "hex" : "0100000001659d0ebe45e4446113776807a0160ab487a56f8386405e07d8d15275f18bb832010000006b483045022100c139f0601bcef52dca990a7a5ae73a6e30ce5f521e2be25e80376338c4d0a84a02201f691b9295c32660d023ff65e8b2793b563f29b66d0c704577785d353e2f66620121029e033dda03e6cf9e0c93ac5b2689d047fd8e559ea0b5cfd1c86062387c672dcdffffffff0180d1f008000000001976a91476d2d121a1bbbc7e4c51f7a7c84437bb3aa1d66d88ac00000000",
    "complete" : true
}
It decodes, can be signed, I have funds and I've sent similar transactions before, but now seems impossible.

Error -25 can be generated by your own client, even before it tries to send it to the network at all.  So I would think it's more likely that there is something wrong with your transaction, and the network is fine.  Perhaps you could explain in detail how you created the transaction.

Your last question (having to recheck blocks) is almost certainly a problem at your end, and unrelated to your transactions being rejected. You should ask it as a separate question, including the exact message (we can't guess much from "I get an error") and details about how you shut down the client previously.

Agreed. They are unrelated problems. I will leave the question for the rawtransaction and see if I can reproduce the other problem for another question. I was seeing strange things and started to think everything was connected. My bad. Thank you!

Your posted transaction has a tx fee of 0.5 XTN:
Version:  1  tx hash 7f1aa3a20163a9d4058940dd6af29b3f7aefc037b2f3b21133a1413a990bc4e7  192 bytes
TxIn count: 1; TxOut count: 1
Lock time: 0 (valid anytime)
Input:
   0: mjKj3fFKUBMfYiozTw4jngpuDQRjarn62F from 32b88bf17552d1d8075e4086836fa587b40a16a0076877136144e445be0e9d65:1      2000.00000 mBTC  sig ok
Output:
   0: mrMEaWKfkJZcAN52VqNxKkF21uvf9HF9G7 receives   1500.00000 mBTC
Total input    2000.00000 mBTC
Total output   1500.00000 mBTC
Total fees      500.00000 mBTC

which exceeds the default max imposed by Bitcoin Core of 0.1 XTN (or BTC). Please try adding the -maxtxfee=<amt> option to bitcoind's command line, and report back if you're still having difficulty.

That was exactly the problem! Thank you! I will modify the question to make everything clear.

@halftimepad you can also add the second parameter to sendrawtransaction, which is a boolean for allowhighfees.

@StephenM347 I did not know that, thanks!

@StephenM347 Great! I'll also try some high fee transactions then. Last time I sent raw transactions there was no fee limit (and lost a few testnet coins in the changes).


text:
CgMiner past version 3.4 cannot see USB Block Eurptors (Windows)
I've been using CgMiner 3.4.1 since late September. It can see my four USB Block Erupters, and works:
 cgminer version 3.4.1 - Started: [2013-11-20 07:48:07]
--------------------------------------------------------------------------------
 (5s):1.223G (avg):978.4Mh/s | A:18  R:0  HW:1  WU:17.4/m
 ST: 2  SS: 0  NB: 1  LW: 37  GF: 0  RF: 0
 Connected to stratum.bitcoin.cz diff 3 with stratum as user joesmith
 Block: 00070bedfe64cbc8...  Diff:609M  Started: [07:48:07]  Best share: 124
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 AMU 0:                | 307.2M/327.5Mh/s | A:12 R:0 HW:0 WU:10.0/m
 AMU 1:                | 267.8M/314.6Mh/s | A: 0 R:0 HW:0 WU: 2.5/m
 AMU 2:                | 280.3M/322.7Mh/s | A: 6 R:0 HW:0 WU: 3.7/m
 AMU 3:                | 127.4M/308.9Mh/s | A: 3 R:0 HW:1 WU:10.5/m
--------------------------------------------------------------------------------

 [2013-11-20 07:48:43] Accepted 1326b92d Diff 13/3 AMU 0
 [2013-11-20 07:48:47] Accepted 3e086003 Diff 4/3 AMU 0
 [2013-11-20 07:48:58] Accepted 487047eb Diff 3/3 AMU 3

But it regularly crashes with a stack overflow.
About a month ago i tried to upgrade to CgMiner 3.6, but it fails to find my USB devices:
 cgminer version 3.6.0 - Started: [2013-11-20 07:49:52]
--------------------------------------------------------------------------------
 (5s):0.000 (avg):0.000h/s | A:0  R:0  HW:0  WU:0.0/m
 ST: 2  SS: 0  NB: 1  LW: 2  GF: 0  RF: 0
 Connected to stratum.bitcoin.cz diff 3 with stratum as user joesmith
 Block: 00070bedfe64cbc8...  Diff:609M  Started: [07:49:52]  Best share: 0
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
--------------------------------------------------------------------------------

 [2013-11-20 07:49:49] Started cgminer 3.6.0
 [2013-11-20 07:49:49] Loaded configuration file cgminer.conf
 [2013-11-20 07:49:51] No devices detected!
 [2013-11-20 07:49:51] Waiting for USB hotplug devices or press q to quit
 [2013-11-20 07:49:51] Probing for an alive pool
 [2013-11-20 07:49:52] Pool 0 difficulty changed to 3
 [2013-11-20 07:49:52] Network diff set to 609M

So i reverted to 3.4.1, living with the semi-daily crashes and having to remember to restart CgMiner. This morning i tested CgMiner 3.8, hoping they fixed its inability to see USB Block Eruptors (and the stack overflow). Unfortunately it still does not see USB devices:
 cgminer version 3.8.0 - Started: [2013-11-20 07:44:46]
--------------------------------------------------------------------------------
 (5s):0.000 (avg):0.000h/s | A:0  R:0  HW:0  WU:0.0/m
 ST: 2  SS: 0  NB: 1  LW: 16  GF: 0  RF: 0
 Connected to stratum.bitcoin.cz diff 1 with stratum as user joesmith
 Block: 70bedfe6...  Diff:609M  Started: [07:44:46]  Best share: 0
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
--------------------------------------------------------------------------------

 [2013-11-20 07:44:42] Started cgminer 3.8.0
 [2013-11-20 07:44:42] Loaded configuration file cgminer.conf
 [2013-11-20 07:44:44] AMU 0 SendWork usb write err:(-7) LIBUSB_ERROR_TIMEOUT
 [2013-11-20 07:44:44] FAIL: USB get_lock not found (3:2)
 [2013-11-20 07:44:44] FAIL: USB remove not already in use (3:2)
 [2013-11-20 07:44:45] No devices detected!
 [2013-11-20 07:44:45] Waiting for USB hotplug devices or press q to quit
 [2013-11-20 07:44:45] Probing for an alive pool
 [2013-11-20 07:44:46] Pool 0 difficulty changed to 3
 [2013-11-20 07:44:46] Network diff set to 609M
 [2013-11-20 07:45:14] Pool 0 difficulty changed to 1
 [2013-11-20 07:45:14] Stratum from pool 0 requested work restart
 [2013-11-20 07:45:14] Stratum from pool 0 requested work restart

So i am, once again, reverted to CgMiner 3.4.1.
What did they break after CgMiner 3.4, and how do i fix it?
WinUSB
Just to preempt people who might suggest it, rather than offering any insight, i re-ran zadiag 2.0.1.162 (Updated 11/20/2013), and "reinstalled" the WinUSB driver for my for USB devices (and rebooted)

No effect.
What is CgMiner 2.8 doing wrong that CgMiner 2.4 did right?
Edit: Using Silicon Labs own VCP (Virtual COM Port driver):

gives the error (in BfgMiner):
usb_devinfo_scan: Error opening device: LIBUSB_ERROR_NOT_SUPPORTED

In CgMiner it gives:
USB init, open device failed, err -12, you need to install a WinUSB driver for - AMU device 1:3
USB init, open device failed, err -12, you need to install a WinUSB driver for - AMU device 3:3
USB init, open device failed, err -12, you need to install a WinUSB driver for - AMU device 3:2
USB init, open device failed, err -12, you need to install a WinUSB driver for - AMU device 3:6
USB init, open device failed, err -12, you need to install a WinUSB driver for - AMU device 3:8
USB init, open device failed, err -12, you need to install a WinUSB driver for - AMU device 3:10
USB init, open device failed, err -12, you need to install a WinUSB driver for - AMU device 3:11
USB init, open device failed, err -12, you need to install a WinUSB driver for - AMU device 3:12
USB init, open device failed, err -12, you need to install a WinUSB driver for - AMU device 3:13
USB init, open device failed, err -12, you need to install a WinUSB driver for - AMU device 6:2
USB init, open device failed, err -12, you need to install a WinUSB driver for - AMU device 8:3
USB init, open device failed, err -12, you need to install a WinUSB driver for - AMU device 8:1

So i've changed it trying every driver with some of the miners. Three are using the libusb-win32 driver, three are using the libusbx.org driver, and the rest are using the Silicon Labs CP210x USB to UART Bridge driver:

Both CgMiner and BfgMiner detect no devices.

cgminer's FPGA and ASIC support was originally taken from BFGMiner. Due to the maintainers of GPU mining being upset over the obsoletion of GPU mining, they forked the project and eventually (poorly) rewrote the FPGA/ASIC drivers. You are seeing the effects of that.
BFGMiner continues to maintain the original (working) drivers, but you will need to remove the Zadig/WinUSB driver and install the official CP210x driver provided by Silabs. (CP210x is the chip used by the Block Erupters)

BfgMiner seems to require the libusb driver. On launch it gives the error usb_devinfo_scan: Error opening device: LIBUSB_ERROR_NOT_SUPPORTED

Only for devices that speak raw USB, not block erupters.

4.10.0 found my old asic usb miner


text:
Command line generated address can't recover with seed phrase, what am I missing?
I have generated a bitcoin address using the following commands along with a ruby script for compression.
First I generate a key using echo "24 word seed phrase BIP 39" | openssl sha256
Then run the below Ruby script to compress the key
# example private key
private_key = "private key that has been generated with previous command"

# --------------------------
# Secp256k1 Curve Parameters
# --------------------------
# y^2 = x^3 + ax + b
$a = 0
$b = 7 # using global variables for convenience

# prime modulus
$p = 2 ** 256 - 2 ** 32 - 2 ** 9 - 2 ** 8 - 2 ** 7 - 2 ** 6 - 2 ** 4 - 1

# number of points on the curve
$n = 115792089237316195423570985008687907852837564279074904382605163141518161494337

# generator point (the starting point on the curve used for all calculations)
$g = {
  x: 55066263022277343669578718895168534326250603453777594175500187360389116729240,
  y: 32670510020758816978083085130507043184471273380659243275938904335757337482424,
}

# --------------------------
# Elliptic Curve Mathematics
# --------------------------
# Modular Inverse - Ruby doesn't have a built-in function for finding modular inverses, so here's one using the extended Euclidean algorithm.
def modinv(a, m = $p)
  a = a % m if a < 0 # make sure a is positive
  prevy, y = 0, 1
  while a > 1
    q = m / a
    y, prevy = prevy - q * y, y
    a, m = m % a, a
  end
  return y
end

# Double - Add a point on the curve to itself.
def double(point)
  # slope = (3x^2 + a) / 2y
  slope = ((3 * point[:x] ** 2) * modinv((2 * point[:y]))) % $p # using modular inverse to perform "division"

  # new x = slope^2 - 2x
  x = (slope ** 2 - (2 * point[:x])) % $p

  # new y = slope * (x - new x) * y
  y = (slope * (point[:x] - x) - point[:y]) % $p

  # return x, y coordinates of point
  return { x: x, y: y }
end

# Add - Add two points together.
def add(point1, point2)
  # double if both points are the same
  return double(point1) if point1 == point2

  # slope = (y1 - y2) / (x1 - x2)
  slope = ((point1[:y] - point2[:y]) * modinv(point1[:x] - point2[:x])) % $p

  # new x = slope^2 - x1 - x2
  x = (slope ** 2 - point1[:x] - point2[:x]) % $p

  # new y = slope * (x1 - new x) - y1
  y = ((slope * (point1[:x] - x)) - point1[:y]) % $p

  # return x, y coordinates of point
  return { x: x, y: y }
end

# Multiply - Use the double and add operations to quickly multiply a point by an integer (e.g. a private key).
def multiply(k, point = $g) # multiply the generator point by default
  # create a copy the initial starting point (for use in addition later on)
  current = point

  # convert integer to binary representation (for use in the double and add algorithm)
  binary = k.to_s(2)

  # double and add algorithm for fast multiplication
  binary.split("").drop(1).each do |char| # ignore first binary character
    # 0 = double
    current = double(current)

    # 1 = double and add
    if char == "1"
      current = add(current, point)
    end
  end

  # return the final point
  return current
end

# -------------------------
# Private Key To Public Key
# -------------------------
# convert private key to an integer
k = private_key.to_i(16)

# multiply generator point by this private key
point = multiply(k, $g) # this point is the public key

# convert x and y values of this point to hexadecimal
x = point[:x].to_s(16).rjust(64, "0")
y = point[:y].to_s(16).rjust(64, "0")

# uncompressed public key format (not used much these days, just showing how it looks)
public_key_uncompressed = "04" + x + y

# compressed public key format (every x value has a y that could be one of two possible points)
if (point[:y] % 2 == 0)
  prefix = "02" # if y is even
else
  prefix = "03" # if y is odd
end

public_key_compressed = prefix + x # only uses the full x coordinate

# -------
# Results
# -------
puts private_key           #=> ef235aacf90d9f4aadd8c92e4b2562e1d9eb97f0df9ba3b508258739cb013db2
puts public_key_compressed

Then hashing the key again with
echo compressed key from ruby script | xxd -r -p | openssl sha256
Then echo hashed key | xxd -r -p | openssl ripemd160
And finally adding 00 to the key
echo 00key | xxd -p -r | base58 -c && echo
The address I get is able to receiving funds, but I can't recover using the 24 word seed phrase using BlueWallet import function. What am I doing wrong?
https://learnmeabitcoin.com/technical/public-key Link to Ruby Script
https://medium.com/coinmonks/how-to-generate-a-bitcoin-address-step-by-step-9d7fcbf1ad0b Link to Openssl Commands

Take your private key, transform it into a WIF and then you should be able to import it to BlueWallet.
How to transform a private key into a WIF:
https://gist.github.com/t4sk/ac6f2d607c96156ca15f577290716fcc

Both answers were correct, I just used the bash script out of the git. Thanks.

You seem to have conflated multiple things here and resulted in a potentially unspendable address, or at least very difficult to spend with standard wallet software.
Wallets that use 24 word seed phrases typically use BIP 39 to produce 512 bits of entropy which is then used with BIP 32 to derive the private keys used in the wallet. Your process does not do any of that. You did not use BIP 39 to produce the entropy; you did not use that entropy with BIP 32 to derive private keys; and you did not use BIP 32 derived private keys to produce your address.
When you import your 24 words into a BIP 39 compatible wallet, they're not going to use your method of deriving the address. They're going to use BIP 39 and BIP 32 to create multiple addresses, none of which are the one you generated.
Since you do technically still have the private key, you can convert it into a Wallet Import Format private key and import that into a wallet to be able to spend your funds.


text:
No connection could be made because the target machine actively refused it
Trying to make a POST request with python from my desktop to my Bitcoin node running on raspberrypi. The two devices are running on the same network both connected by ethernet. I have been able to make a POST request using curl from the node's command line (ssh from the desktop). The command looks like this:
curl -v -u <rpcuser>:<rpcpassword> -d '{"method":"getblockcount","params":[],"id":1}' http://localhost:8332/
It gives me the output just fine, but when I write a python script from my desktop to send the same POST request, it gives me the error in the title. The python code looks like this:
request = requests.post(url=self.url, json={"method":"getblockhash","params":[0],"id":1}, headers={'Authorization':'Basic <base64 encoding of rpcuser:rpcpass>'})
I have tried both the auth and the headers parameter and they both give me the same error. How can I pass in the rpcuser and password to successfully make a request?

When making requests to a different network device, you need to replace localhost with that device's IP address. On a Raspberry Pi specifically you can use this command to find it:
hostname -I

The credentials should be sent using Basic access authentication. This means you need to set the Authorization header field to Basic <credential>, where <credential> is the Base64 encoding of username and password joined by a single colon :.

I have a couple questions. Do I need to replace localhost with the pi's IP address if the two devices are connected to the same network? The request seems to go through without replacing localhost. Second, I have created an authorization header that looks like: header = {'Authorization' : 'basic <base64 encoding of rpc_user:rpc_password>'} and it does not seem to do the trick.

I have tried changing localhost to the pi's IP address and I have created a header for the request. It is still not working. Would you have any idea why?

"It is still not working" is not a helpful problem description. What error do you get? What network traffic do you observe?

Sending the request gives me the same error: "No connection could be made because the target machine actively refused it."


text:
What is the transaction hash preimage for different values of SIGHASH (not SIGHASH_ALL) in P2PKH?
I have a few questions regarding the transaction hash preimage when signing with different values of the SIGHASH flag in the case of the P2PKH script.
I know what the transaction hash preimage looks like in case of SIGHASH_ALL, but what does it look like for other values of this flag.
So let's say our transaction has 3 inputs and 4 outputs and we can denote it as T(I1, I2, I3; O1, O2, O3, O4), the preimage in the case of SIGHASH_ALL will be as follows.
Let's start with the input. We take all inputs as they are (its full content). After that, we clear the scriptSig field of all inputs and set the length of the scriptSig field in all inputs to zero (0x00). Then, just for the input we're signing, we  set its scriptSig field to the scriptPubKey from the output (UTXO) that this input points to. Also, we will set the length of the scriptSig field in this input to the length of this newly added script scriptPubKey. The length of the scriptSig field in other inputs remains zero (0x00), and the scriptSig field remains empty. When it comes to the outputs, we copy their complete contents and add them to the previously described slightly modified contents of the inputs. Finally, we additionally append 0x01000000, which indicates that it is a SIGHASH_ALL type of signature.
This is how it works in the case of SIGHASH_ALL, but how does it work for other values of this flag.
My assumption is that it is exactly the same process, the only question is which inputs and outputs are taken into account. Therefore, the transaction hash preimages for the different values of the SIGHASH flag are as follows (I took into account the values defined in the Master Bitcoin book):

NONE (0x02) - Signature applies to all inputs, none of the outputs

for inputs, absolutely the same story that I described for SIGHASH_ALL applies
outputs are not taken into account (they are not part of the transaction hash preimage, similar as scriptSig field of other inputs is also not a part)
append 0x02000000 to the end

SIGNLE (0x03) - Signature applies to all inputs but only the one output with the same index number as the signed input

for inputs, absolutely the same story that I described for SIGHASH_ALL applies
only the content of the output whose index corresponds to the input index is taken into account (eg if we want to sign I2, we will take inputs I1, I2 and I3, but only output O2)
append 0x02000000 to the end

ALL|ANYONECANPAY (0x81) - Signature applies to one input and all outputs

only the input that we sign is included in the transaction hash preimage, the other inputs, i.e. their content, are not part of the transaction hash preimage in any form (we just ignore the other inputs, a similar scenario that we would have if the transaction had only one input and the SIGHASH_ALL)
for outputs, absolutely the same story that I described for SIGHASH_ALL applies (we take the entire content of all outputs)
append 0x81000000 to the end

NONE|ANYONECANPAY (0x82) - Signature applies to one input, none of the outputs

for inputs, absolutely the same story that I described for 0x81 (ALL|ANYONECANPAY) applies
outputs are not taken into account (they are not part of the transaction hash preimage)
append 0x82000000 to the end

SINGLE|ANYONECANPAY (0x83) - Signature applies to one input and the output with the same index number

for inputs, absolutely the same story that I described for 0x81 (ALL|ANYONECANPAY) applies
for outputs, absolutely the same story that I described for 0x03 (SIGNLE) applies
append 0x83000000 to the end

So my questions are:
1. Is this how it works?
2. Are there any other values for the SIGHASH flag that I should cover?
3. Is there some related work/paper/standard that explains this (perhaps for other scripts, like P2WPKH etc.)?

Not a full answer, but for P2WPKH/P2WSH this is described in BIP143 (the entire document is about just the sighash construction). For P2TR key path spends this is described in BIP341 (see "Common signature message", plus "Taproot key path spending signature validation"). For P2TR tapscript spends this is described in BIP342 (reusing BIP341's "Common signature message", plus its own "Signature validation").

@PieterWuille Thanks for the reply Pieter. I will look at the standards you wrote. Do you perhaps know the answers to the other questions (especially the first). I would say that is the logic to follow.

I don't have the time to go over that in detail now. There are several answers on this site on the topic of sighash computation, though I'm not sure if any cover sighash flags other than ALL.

Check out https://raghavsood.com/blog/2018/06/10/bitcoin-signature-types-sighash

Well, based on this article, the principle I already described is followed with some additions (only those additions are written below):
(if you want to check for yourself, please note that the preimage on the web page is presented in reverse - at the beginning is the mark of the signature type , while at the end is the transaction version)

NONE (0x02)

value of sequence field of inputs that are not the input for which we are making signature is set to 0x00000000
value of tx_out count field is set to 0x00

SIGNLE (0x03)

value of sequence field of inputs that are not the input for which we are making signature is set to 0x00000000
the value of the tx_out count field depends on the input/output index (index_s) we are signing; for example, if the index_s = 2, we put the value for count field tx_out_count = index_s + 1, which is 3 in this case
outputs to index_s  (let's say index_s = 2), so outputs 0 and 1, will have the value field set to 0xffffffffffffffff, and the script length field to 0x00, while the script will not exist at all
index_s output we are signing in "standard way" (we just take its entire content)
outputs after index_s we don't take into account

ALL|ANYONECANPAY (0x81)

we only take into account the input we are signing and we do it in a standard way; other inputs are not taken into account at all (this is different from outputs)
all outputs are signed in the manner described for SIGNHASH_ALL (0x01)

NONE|ANYONECANPAY (0x82)

for inputs, absolutely the same story that I described above for 0x81 (ALL|ANYONECANPAY) applies

SINGLE|ANYONECANPAY (0x83)

for inputs, absolutely the same story that I described above for 0x81 (ALL|ANYONECANPAY) applies
for output, absolutely the same story that I described above for 0x03

The strange is that when only one output is signing, then the outputs up to it (up to its index) are taken into account (value at 0xffffffffffffffff and script length at 0x00), while this does not apply to inputs. What confuses me is that on the website, for 0x81, 0x82 and 0x83 it says that the input with index 0 is signed, although actually in the example the input with index 1 is signed. Therefore, I do not know if the inputs up to the one that is signed are also taken into account (as in the case of output), because maybe the writer thought that he is really signing the input with index 0, not 1. So there are no inputs up to it, since it is the first in sequence. Another possibility is that he really wanted to sign the input with index 1 (so the inputs up to it are not really taken into account), but writer did not put a good title of the given section.
Does anyone have any more information, or maybe can confirm this?


text:
Why is the discount on segWit data exactly a factor of 4 and not 5, 6 or something higher?
According to BIP141, the formula for calculating block/transaction weight is:
BASE SIZE * 3 + TOTAL SIZE

According to Bitcoin wiki (and also based on the above formula):

Each byte of the segwit marker, flag, and witness fields counts as one weight unit
Each byte of the other fields in the transaction counts as four weight units

This puts a new limit to transaction size close to 4MB.
So my question is: Why is the discount, that is, the factor, of segWit data exactly 4? Why don't we use a higher factor, for example 5 or 6? That way, we would get an even bigger discount and have even bigger blocks and thus a bigger number of transactions that we can process in the same time.
Murch has left links to some of the similar questions. However, none of these answer the question why the factor of 4. Jannes said in his answer that it is because TXout is 1/4 the size of TXins. This makes it clear to me why 2 or 3 was not taken as a factor. We simply wouldn't have big enough benefits. However, it is still not clear to me why a larger factor was not taken, such as 5, 6 or something even higher.

Does https://bitcoin.stackexchange.com/q/43596/5406 or https://bitcoin.stackexchange.com/q/108333/5406 answer your question?

If either of these other topics fully answered your question, please flag your own topic as a duplicate of the respective topic. This will ensure that other users find the corresponding topic when they rediscover your topic. If your question has not been fully answered, please edit your question to clarify how your question exceeds the linked topics.

@Murch None of the accepted answers gives an answer to the question why exactly the multiplier 4 is used and not 5 or 6. However, Jannes in his answer in the first linked question talks about it being because TXout is 1/4 the size of TXin, although he didn't go into specific details. The good thing is that he posted links that I think go a little deeper into it. I will go through those reddit discussions (that he left) in detail and see if I understand. If so, I will answer the question myself, unless someone has already done so.

Thanks, that would be great

@Murch Hey, Murch. It seems that the factor of 4 was chosen empirically (based on experience) so that segWit gets a sufficient discount, without damaging the network (which would be the case if the factor were higher). I'm not sure in what ways a larger factor would harm the network, but this text talks about it. I will edit a question a little bit because I see that many did not understand exactly what I wanted to ask. I hope that someone who knows Bitcoin better will answer at some point.

Thanks, sounds good

It would be nice if you could turn that into an answer, @dassd.


text:
Blockchain vs. Banks: which one has more affordable transaction fees?
Maybe one of the issues researchers are trying to solve in blockchain protocols like Bitcoin or Ethereum is removing / decreasing "transaction fees". However, if we compare blockchain transaction fee with traditional centralized bank protocols (Visa or MasterCard) which one has more affordable transaction fee? (Or which one is more expensive? blockchain (bitcoin/Ethereum)? or Visa/MasterCard?)

Bitcoin's blockchain transaction fees are market-based, so they fluctuate based on what fees miners are willing to mine:

Currently, they are around $0.75.
First of all, one major difference is that Bitcoin's fees are flat (not based on the transaction amount) and Visa or Mastercard's interchange fees are percentage-based. This means that the fee for larger transactions on the Bitcoin network are the same for very small transactions. You can find Visa's fees, for example on their website: Visa Interchange Rates, which depend on the type of transaction, but they generally are over 1%. Based on that, any transaction above $75 will be cheaper on the Bitcoin blockchain.
Now, there is a secondary layer network on Bitcoin called the Lightning Network, where you can do microtransactions, which are not all immediately posted to the blockchain, but can have drastically lower fees because nodes have to compete to route payment channels, see Bitcoin Lightning Network Creators: Fees Will Be Effectively Zero. The only time you pay the blockchain tx fee is when the channel is created or closed.

If fees for debit card transactions are capped at 0.2% in the EU, does that mean that debit cards in the EU are cheaper than Bitcoin for any transaction under $375? Unlike bitcoin, the purchaser doesn't pay any transaction fee when purchasing using a debit-card (you can argue that indirectly they do but often retailers cannot charge cash purchasers a different price so this is rather moot).

Yeah if that's the case, and you don't use LN. Purchaser doesn't pay the fees directly, but the merchant can charge the customer less if they pay in bitcoin, for example. But, the merchant would also have to factor in the cost of transferring that to fiat if that's required.

if we compare blockchain transaction fee with traditional centralized banks protocols (Visa or MasterCard) which one has more affordable transaction fee?

That isn't necessarily a relevant comparison. At least, not for me.
I make most purchases online using a debit card. The bank doesn't charge me a fee for this type of transaction.
I make some regular payments (monthly bills etc) using online banking. The bank doesn't charge me a fee for those transactions. I use something called the Faster Payments System (FPS) which usually takes a few minutes for the payment to show up in the recipient's account. The banks charge each other a flat fee (GBP 0.03) per transaction but that fee doesn't appear anywhere in my bank statements.
Since Bitcoins were conceived, at least partly, as an electronic equivalent to fiat cash, you can also compare the Bitcoin transaction fee with the transaction fee you pay when purchasing something using banknotes and coins - again zero.
So it is only certain forms of payment that result in fees for the purchaser using payment systems supported by banks. In many cases the apparent fees to the purchaser are zero. You can avoid most transaction fees with a little care.
For businesses or a retailer, fees will be more evident.
For a consumer making a purchase, Bitcoin transactions might only be cheaper where the the transaction

can wait for several blockchain confirmations or
is one where the recipient takes the risk of trusting it will confirm and
involves no conversions to fiat (e.g. retailer has a bitcoin wallet)
involves no use of a BTM (Bitcoin ATM)
involves no payment processor (e.g. Bitpay etc)
is a higher value transaction
where you cannot pay in fiat banknotes
where you cannot pay using fiat online-banking or fiat debit card
where the alternative would be a fiat credit-card that you don't pay off in full when due -- or some other relatively expensive method that is usually avoidable in my part of the world.

of course there are costs to running any payment system, however for payments in fiat currency, in my part of the world, those costs are paid indirectly by everyone regardless of their chosen method of payment - so they are mostly not a factor in choice of payment method.


text:
Complete definition of 'tx_witness' data structure used in 'tx' data structure
I'm reading the Protocol Documentation page for the 'tx' data structure and cannot find a completely clear definition of the 'tx_witness' data structure.
After the 'tx_out' table, there is short comment stating that "The TxWitness structure consists of a var_int count of witness data components, followed by (for each witness data component) a var_int length of the component and the raw component data itself."
Could someone post a table, similar to others on the Protocol Documentation page, defining clearly how a 'tx_witness' data structure should be formed?

In Bitcoin Core, the scriptWitness property (for the CTxIn class) is serialized from a CTransaction as a std::vector<std::vector<unsigned char> >, so I would imagine the serialized version would look something like:
TxWitness:

+------------+-------------------------+------------------------+
| Field Size |        Description      |       Data Type        |
+------------+-------------------------+------------------------+
| 0+         | witness_component count | var_int                |
| ?          | witness_components      | witness_component[]    |
+------------+-------------------------+------------------------+

WitnessComponent:

+------------+------------------+-----------+
| Field Size |   Description    | Data Type |
+------------+------------------+-----------+
| 0+         | component length | var_int   |
| ?          | component        | uchar[]   |
+------------+------------------+-----------+

References:

https://github.com/bitcoin/bitcoin/blob/master/src/primitives/transaction.h#L67
https://github.com/bitcoin/bitcoin/blob/master/src/primitives/transaction.h#L254
https://github.com/bitcoin/bitcoin/blob/master/src/script/script.h#L676


text:
what's CCoinsViewDB::GetHeadBlocks for?
I have google a lot, there exists little information, confused with the code comments
Retrieve the range of blocks that may have been only partially written. If the database is in a consistent state, the result is the empty vector. Otherwise, a two-element vector is returned consisting of the new and the old block hash, in that order.

why there exists old & new block, their function?

Bitcoin Core does this thing called non-atomic flushing. What that means is that the database, instead of being updated atomically (i.e. everything is written at the same time, or nothing is written), has data written to it over time. If the database crashes, with non-atomic flushing, there will be some data written, and some data that is not written. This is different from atomic flushing where either all of the data was written, or none of it was.
Non-atomic flushing allows Bitcoin Core to skip validation of things it has already validated and then just flush things to the database later after a crash or unclean shutdown. But in order to know where it has validated up to, it has to store that block hash (where it has validated up to and where it is flushing up to). It also has to store the block it started at (the block the database knew up to when flushing began).
This is where GetHeadBlocks() comes in. When Bitcoin Core begins flushing, it first writes those two blocks, the old one where the database head was at, and the new one, where the database head will be once flushing finishes. In the event of an unclean shutdown or database crash, these values are already written to the database so it can pull those out of the database, know where its last known good database state was at, and know where it has validated up to so it can skip full validation and just build the database data and flush it. If there was no unclean shutdown or crash, GetHeadBlocks() would return an empty vector.

For example, suppose the database was at block 50, and it is flushing to block 60. When it begins flushing, the hashes of blocks 50 and 60 are written to the database. Suppose that the computer suddenly loses power when it has only flushed up to block 55. When the node comes back on, it will call GetHeadBlocks() and get the hashes of blocks 50 and 60. Now it knows that it was mid-flush when it uncleanly shutdown. So it then rebuilds what the database would be from blocks 50 to 60 but does not perform full validation. It then flushes the remaining data and removes the hashes of blocks 50 and 60 from where they were written.

When a crash happens during the flush from 50 to 60, it will have some changes from every block between 50 and 60, not neatly everything up to 55 and nothing above. This is a detail and doesn't impact the rest of the explanation, but it otherwise raises a question: if you've synced everything to 55, why not write that to the db, to avoid processing of blocks 50-54? If it's a mix of changes from all, you can't do that.

Your answer lies in the code.
Check where GetHeadBlocks is being used..
https://dev.visucore.com/bitcoin/doxygen/class_c_coins_view_d_b.html
The caller graph indicates that it's being used by CCoinsViewDB::BatchWrite. The assert statement in BatchWrite will abort the function execution if the latest head does not match the hashblock passed as an argument.
My 30 second research seems to indicate that it will return the block hashes of the old & new block when it's in a syncing state. The BatchWrite is also responsible for updating the best block hash (check doxygen).

you answer too mindless..... why there exists old & new block, their function?


text:
How can importprivkey compromise wallet security when importing a publicly known private key?
A question was asked on reddit over here which I gave a reply: https://www.reddit.com/r/Bitcoin/comments/3khrvm/how_do_i_use_private_keys_to_receive_bitcoin/
However, luke-jr replies with:

Don't do this. You compromise your wallet's security to import a private key that others know.

without further elaboration. Can someone explain what he's talking about?

The problem is rather subtle and results from a combination of behaviors.
First of all, it is perfectly safe to use someone else's private key, at least in a standalone sense. Suppose the private key is P and the public address is A, and suppose you want to spend their money. Then you scan the blockchain for transactions outputs that are addressed to A. When you see one, you create a new transaction to some desired output address B (whether you're paying yourself or paying someone else), and sign it with the private key P. No problems here.
The problem starts when we're talking about wallet software. If you "import" a private key P into your wallet, then it gets added to your personal pool of private keys (and their associated public addresses). Whenever you make an outgoing transaction, some amount will almost always be sent back to yourself as change. If the change goes to address A (with associated private key P), then other people who know the private key P can also spend this money. Ultimately this means that if you import someone else's private key, you might lose control of your own money in some circumstances.
As other people have mentioned, the safe way to handle this situation is to "sweep" the coins associated with address A (using private key P) into addresses that you have exclusive control over. In other words, use that private key to pay yourself, but never use the address as an output for change.

As an analogy: Suppose you're in a hall with numbered lockers. It's always possible to deposit money into any locker (only need the address, not the private key). Locker #0 can be opened by both your friend and yourself. Locker #1 and #2 are only openable by you.
If you have cash in lockers #1 and #2, this belongs to you and you alone. Now when you make a transaction, you take cash out of one or both of these lockers, then return some as change. You can also take cash out of locker #0, no problem. But if you return some change into locker #0, then you lose your exclusive control over that cash. So you must only return change to your own lockers #1 and #2, not the shared locker #0.

If Eve gives you a private key that contains Bitcoins in exchange for a pile of gold coins, she still has a copy of the private key, and can take the Bitcoins back, leaving her with both the gold coins and the Bitcoins.
Instead, tell Eve to send Bitcoins to your address.


text:
How to retrieve POST data that contains JSON
I have never used JSON before and am trying to retrieve the values POSTed to my site from coinbase. But I have no idea how to.
Information about the IPN and callback can be found here: https://coinbase.com/docs/merchant_tools/callbacks
To be more specific, what I understand so far is that I can use json_decode($jsonData); to turn the JSON data into PHP data. But how do I set the variable $jsonData?
This is the response that is supposed to be sent:
{"order":{"id":null,"created_at":null,"status":"new","total_btc":
{"cents":100000000,"currency_iso":"BTC"},"total_native":
{"cents":2263,"currency_iso":"USD"},"custom":"123456789","button":
{"type":"buy_now","name":"Test Item","description":null,"id":null},"transaction":
{"hash":"4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b","confirmations":0}}}

Could you put var_dump($_POST); in your callback and post the output?

I just tried
$data = var_dump($_POST);
file_put_contents('coinbase.txt', $data);
with no luck.

Ah, of course. It's been a while since I've done any php. Try $data = print_r($_POST, TRUE); file_put_contents('coinbase.txt', $data);

I got Array
(
)
It is a step forward though!

Do you have a shell on this computer? If so, you could do nc -l 8080, then set the callback url to http://yoursite.com:8080/ to see exactly what it's sending.

I have no idea how to do that to be honest.

If print_r is displaying "Array ()" then the array returned is is empty.

I added the data that I am told is being sent. I believe the data is an array nested within an array in JSON format.

$data = json_decode(file_get_contents('php://input'), TRUE);
$text = print_r($data,true);
file_put_contents('coinbase.txt', $text);

This actually sends the following information to a text file:
Array
(
    [order] => Array
        (
            [id] =>
            [created_at] =>
            [status] => new
            [total_btc] => Array
                (
                    [cents] => 100000000
                    [currency_iso] => BTC
                )

            [total_native] => Array
                (
                    [cents] => 2270
                    [currency_iso] => USD
                )

            [custom] => 123456789
            [button] => Array
                (
                    [type] => buy_now
                    [name] => Test Item
                    [description] =>
                    [id] =>
                )

            [transaction] => Array
                (
                    [hash] => 4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b
                    [confirmations] => 0
                )

        )

)


text:
How can I stop Electrum re-using change addresses?
I had three addresses containing BTC in my main Electrum wallet.
I then performed more than three sends, to addresses not in my wallet.
The first three sends used main wallet addresses to send BTC from, depositing the change each time in the first change address where it gathered.
Sends after that sent BTC from my first change address, but they sent any change back to the same change address, which isn't ideal. How can I stop Electrum sending change to the change address it originated from, in these cases?
Update
According to Electrum documentation, addresses can be frozen. This seems to only affect where BTC are taken from, however; the docs don't say how to affect where change goes.

Electrum waits for confirmations to create new addresses, so if you make new transactions before the previous ones are confirmed, you'll end up reusing the existing change addresses.

Thanks for clarification. So there's no way to force it to use a new change address in this situation?

To force that behavior you'll need to create the raw tx yourself, I think.


text:
are all nodes validate each transaction added in a new block?
are all nodes validate each transaction added in a new block?
Because what if someone said I have completed block and added invalid transaction? and if others node just accepts a block without validating a transaction.

are all nodes validate each transaction added in a new block?

Yes, each full node checks each transaction and block to make sure they are valid according to the network rules.


text:
Farming with CPU in my Lan
I have recently built an internet network for my entire condominium to use for a very cheap price, and i thought, why not farm bitcoins with it using users CPU?
I heard about coffee miners, but i need something more automatic, that doesn't need presence of a running Kali-Linux. I thought about using DNS, an html first page that injects javascript in each visited page from the AP's... but didn't figure it out yet.
Is there any way to do it?
thanks in advance

This is extremely unethical, and depending on your jurisdiction, illegal. You should not do this.

The best way to succeed at doing this would be to get a lawyer, move to a new country, or prepare for the possibility of doing hard time.

you need to clarify whether or not your getting customer's permission

Multiple things here.  Shall address.
Methodology
The true answer here is this:  you cannot currently mine Bitcoin (and gain any kind of profit) with a CPU.  So that would be a "no" you can't with any effectiveness mine Bitcoin with a CPU.
Bitcoin runs on the SHA-256 algorithm.
CPU mining will, at this point in time, never generate any amount of usable Bitcoin.  Bitcoin mining is done with ASIC hardware.  ASIC stands for application-specific integrated circuit.  These are powerful machines that are built only and specifically to use the SHA-256 mine Bitcoin, thereby rendering other methods extremely unprofitable.
(Other coins have other ASICs that utilize that particular coin's mining algorithm.)
In another method of mining Bitcoin, people mine different coins with GPUs and then convert their earnings into Bitcoin.
Terminology
Farm - a farm is a group of machines that are used to mine cryptocurrency; farms can be comprised of 3 or 4 individual mining rigs or a warehouse that houses thousands of pieces of specialized cryptocurency mining equipment
Mine - mining is the process of using CPUs, GPUs and ASICs to solve algorithmic computational math problems for which they then receive a reward in a specific amount of specified cryptocurrency
So, one does not "farm" Bitcoin, one "mines" Bitcoin and may or may not have a farm to do so.
Feasbility
Now, whether you should or should not utilize network resources that are not your own to create a source of income without the knowledge of all parties involved would be a different question.  You can do whatever you want to do in life, "good" or "bad"-- there will just eventually be consequences that will mirror the choice that was made.  With this specific matter, there are ethical and legal ramifications at stake.

It is unethical to use other people's computers to mine without their explicit consent.  End of story.
The fact that you're providing them some other service at a discount doesn't give you the right to use their computers without their consent.  If you feel you deserve more, raise your prices.
Or, you can offer a deal: "Internet access for $XXX if you agree to let me use your computer to mine." But then you'll have no need to do this via code injection or similar hackery; just have them install the necessary software.  However, my guess is that unless your discount is quite exceptional, your clients will be unhappy as soon as they see the jump in their electricity bills.


text:
How to find reward of total bitcoin?
I have been developing an application for few coins to get details of the coin, it's more like https://masternodes.online/, where we need to show the ROI, Nodes, required, Minimum Worth of a bitcoin, for those things, I need to find reward of bitcoin first.   Could you let me know how to find reward of bitcoin(not for single transaction) and with that how to calculate ROI and other stuff?

what do you mean "reward of bitcoin"?