text:
An "Almost" decentralised currency
I've been interested in Bitcoin for a while. I've been thinking I'd like to give it a go and see if I can make my own cryptocurrency, just to see if I can.
I run my own small web hosting company, the main reason why I don't want to accept Bitcoin is its price volatility. I mean, at one point it was worth $1000 and now its worth $315.
I was wondering, from purely an economics standpoint, would a currency in which all payments, transactions etc ... where decentralised work if one key part was centralised.
I'd like to make all clients download a text file once a week. In the text file would a number, and that number would tell all of the transaction verifiers how many new currency units can be created in any 24 hour period.
I would like to use this file to control the rate at which new currency units are created, there would be no overall limit like Bitcoins 21M. The value would be controlled by controlling the number of currency units that can be created in any 24 hour period.
So since I know nothing about economics I was wondering, would this work?

Do you mean a currency based on the technology Bitcoin uses? Or based on any technology?

@DavidSchwartz I mean a currency that I create myself, completely from scratch. I'd use some of the ideas from Bitcoin though.

I don't think that “almost decentralized” makes sense as a concept. It either is centralized or decentralized. (if it has a single point of failure, it is centralized, no matter what you do)

This is the proverbial veggie burger with bacon. There are plenty of people who like veggie burgers. And there are plenty of people who like bacon. But there are very few people who like both.
You have a cryptocurrency that's not run by a government. But it also has a central authority that can inflate it and regulate it at their whim. There are people who like these revolutionary cryptocurrency systems that are not run by governments. And there are people who fear deflation and like  currencies that can inflated as deemed suitable by a responsible steward. There are just very, very few people who like both of these things.
You will have to answer this very hard question -- "Why would I want to use a store of value that lets you tax my stored value as you wish?" And "Why should I use a currency that's not backed by a government and not subject to political controls when I can use currencies that are?"

Would it be more appealing if, for example, there was a limit built into the software itself? How about the software only accepting the value within the text file if the value in the text file is <= 0.5% of the total number of currency units in existence?

@Francis It's very hard to predict what would happen. I guess it would probably depend on what the perceived advantages were. Let me just point out that your approach is, IMO, totally backwards unless this is just a small piece of what you're thinking about. First you create value, then you figure out how to distribute it. You seem to be working on just the second part. It's like figuring out how you'll help the world with the billion dollars you'll get somehow. A fun mental exercise, but without a plan for how to get the value, fairly pointless.


text:
What is a thin client?
I've heard that if you don't want do download gigabytes of data just to use bitcoin you gotta use a thin client. But what is a thin client?
What are the main advantages of a thin bitcoin client and what defines it as such?

Related: http://bitcoin.stackexchange.com/questions/2712/thin-client-list

@NickODell Instant related to comment. Bot?

No, just no life.

A thin client is a program which connects to the Bitcoin peer-to-peer (P2P) network but which doesn't fully validate transactions or blocks.  That is, it's a client to the full nodes on the network.
Most thin clients use the Simplified Payment Validation (SPV) method to verify that confirmed transactions are part of a block.  To do this, they connect to a full node on the P2P network and send it a filter (called a Bloom filter) that will match any transactions affecting the client's wallet.  When a new block is created, the client requests a special lightweight version of that block called a Merkle block.
The merkle block includes a block header, a relatively small number of hashes, a list of one-bit flags, and a transaction count.  Using this information---often less than 1 KB of data---the client can build a partial Merkle tree to the block header as illustrated below.  If the hash of the root node of the partial Merkle tree equals the hash of merkle root in the block header, the SPV client has cryptographic proof that the transaction was included in that block.  If that block then gets 6 confirmations at the current network difficulty, then the client has extremely strong proof that the transaction was valid and is accepted by the entire network.

(Image taken from MIT-licensed Bitcoin.org developer documentation.  I'm also the author of that image.)
The only major downside of the SPV method is that full nodes can simply not tell the thin clients about transactions, making it look like the client hasn't received bitcoins or that a transaction the client broadcast earlier hasn't confirmed.

Good informative answer, although not all that concise. Accepted.

I doubt any answer could be equally informative yet more concise.

@GeorgeKimionis great idea!  Linkified "thin clients" in the first sentence with that link.  Thanks!

@DavidA.Harding, What's the difference betwen "thin client" vs "SPV client"?

@Pacerier No difference, but you do need to check context.  An SPV client is a client that ensures received payments connect to the header of a block on the most-proof-of-work block chain.  A "thin client" and a "lightweight" client are usually just other names for an SPV client, but sometimes people use those terms to refer to server-trusting wallets that don't check headers at all, such as the Coinbase app or BlockChain.info.

Thin client is one that won't download whole blockchain locally on your device. They are useful for those that have small capacity hard-drive or using mobile devices.

So what parts of the blockchain does it download?

@saloalv just the part it needs to: 1. determine your current balance, and 2. create new transactions from your address(es). Typically just a few blocks. And it can even throw old blocks away after certain outputs have been spent.

source: Stack Exchange

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

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

sort: votes


text:
Is Bitcoin given as a gift taxable?
Question by someone who is new to Bitcoin. Bitcoin mining is considered taxable income in the US. However, if it's given as a gift, then should it be taxable under US law?

This is probably better for Money.SE as it doesn't really have anything to do with Bitcoin; it would be the same for any sort of  income.
However, my understanding of tax law with respect to gifts is roughly this:

Money, goods or services that you earn from working, business or investing are taxable income to you.
If you decide to give some of that money to someone else, that's your business; but you still earned it, and it's still your taxable income.  Giving it away doesn't change your taxes at all.  The IRS doesn't really care whether you gave it to your friend or used it to buy 300 pounds of jellybeans.
Within certain limits, the gift is not taxable income to your friend (who didn't earn it).  However, above those limits, it can be subject to gift tax.  I think beyond $13,000 per year, you have to start keeping track of such gifts; gift tax does not actually kick in until a larger number, but it counts gifts spread across several years.
The one major exception is if you give the money to a registered charitable organization.  Then you can deduct the gift from your income, again up to certain limits (usually 50% of your income).

Disclaimer: If you want tax advice, talk to a professional who's qualified to give it.  I'm not.

Because it's all about that Basis, 'bout that Basis, no Trouble...
Yeah it's pretty clear the IRS wants its due,
but I can give it, spend it like I'm supposed to do,
'cause I got that Bitcoin that all the feds chase,
and all the right coins in all the right places...

This is definitely helpful to know for my purposes. Although I am more likely to receive Bitcoin than give it. Thank you!

I think you can buy Bitcoin, hold it for a year, and then give it someone without having to pay any tax on the increase in value (if any) because you never materialized that increase in value. This won't work if you received the Bitcoins as compensation, of course, because that receipt is a taxable gain.

@DavidSchwartz: I guess the question is, when you give it to your friend, what does their basis become?  If it is the same as your basis, then they will owe capital gains tax if they sell it for more than you paid, and the IRS gets the same money in the long run.  But if their basis is the market value at the time of the gift (i.e. a "step-up") then the two of you come out ahead.  I know that there is a provision for a basis step-up when assets are inherited, but I don't know about ordinary gifts.

@DavidSchwartz: Yeah, according to https://www.firstrepublic.com/community/life-and-money/wealth-transfer/gifting-to-family-members-pitfalls-and-benefits, there is no step-up for ordinary gifts.  So when you give your bitcoins away, you have to tell the recipient what your basis was (i.e. how much you paid for them), and it will be their responsibility to pay capital gains tax (or claim a capital loss) if and when they sell them for more (or less) than what you originally paid.

This may not apply if you give the bitcoins to a registered non-profit charity, since they won't have to pay capital gains tax.  But they might still need to know the basis for record-keeping purposes.

@NateEldredge I'm pretty sure that rule doesn't apply to a pure commodity. This isn't a stock, a debt instrument, real property, or any of the things covered by that rule. I believe the same rules would apply as when a farmer gifts crops to family members. (Does that make the recipient's basis zero?)

@DavidSchwartz: I don't think there's a difference between bitcoins and any other capital asset here.  I'm now looking at IRS Pub 551, section "Property Received as a Gift".  Note that it talks in general about "property" which Bitcoins certainly are.  And it restates the rule: if you give property that has appreciated, the recipient's basis equals the donor's adjusted basis.  (There is a different rule if value at the time of donation is less than the donor's basis.)

if giving Bitcoin as a gift - it would depend who the recipient is and how they claim it.
Basically if they are reporting it as income, or taxable benefit then there should be taxes.

Your point seems to be closely related to what Nate already told us in his more comprehensive answer. Perhaps you could expand your answer a bit to make it more useful?

essentially, if Bitcoin was given to an organization who decided to claim it as income - then it would be taxable.

as of dec. 07 2017, not taxable if you are the receiver, taxable if you are the giver .
however, since technology is outpacing traditional governance , here are the best ways for both the sender and receiver not to get taxed (also, how to get rid of tax by sending a gift to your own self) :
1.) buy a truly anonymous coin in bulk (ex. monero, zcash, electroneum, vertcoin, etc) , declare a capital loss,create a lost/stolen report (monero and electroneum is not app dependent, buy private key dependent , just tell them you lost the paper copy and have not created a virtual copy and can't memorize over 30 wallet characters)  send that to another anonymous coin wallet that you own (it is untraceable at this point), send it to your friend as a gift, no tax on both of you.
2.) to get rid of tax yet earn bitcoin in secret : buy anonymous coin, declare a capital loss, create a lost/stolen report,  send it to another anonymous coin wallet that you own, convert it to an unknown bitcoin wallet (make sure that it is not a wallet provided by an exchange, or ever been used in an exchange) , wait for those bitcoins to grow, then send it as a gift to another bitcoin wallet of yours that is connected to an exchange. discard or don't use the unknown wallet, create a new one if you plan on repeating this method.
3.) improved version of method #2 : instead of declaring it as a gift, wait for the atomic swap . it will convert your monero to bitcoin without going thru the blockchain. it's like buying monero, declare loss, lost/stolen report, atomic swap (yes, after the lost/stolen report, they can still check the blockchain for any movements and if the US government starts to be too strict about it calling you a liar, then atomic swap will keep the moneros moving, but without any trace at all) to bitcoin, send as if it was wrongly sent by someone to you as a gift (you know, like leaving a short message like "happy bday pedro! i give you these bitcoins as gifts!"  even though you don;t know any pedro) , then it's non-taxable anymore

The question was not about tax evasion, and what you have described is likely not legal in many jurisdictions.

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


text:
How did Nakamoto untraceably pay for registering bitcoin.org?
Wikipedia says "Nakamoto created a website with the domain name bitcoin.org" and "transferred several related domains", while bitcoin.org says it was "originally registered and owned by Bitcoin's first two developers, Satoshi Nakamoto and Martti Malmi".  A 2014 businessinsider.com article says bitcoin.org was first registered in 2008 via anonymousspeech.com, and that Malmi stated bitcoin.org was "originally created by Satoshi", and Malmi's first contact with Nakamoto was in 2011 when bitcoin.org was transferred to Malmi.
The article also says anonymousspeech.com accepted cash and E-gold.  Did Nakamoto pay for the original bitcoin.org registration, and used cash or E-gold (paid for with cash) to do that and keep his origins untraceable?  Or is it possible that somewhere in history is a non-anonymous payment of some kind that would finger Nakamoto?  For example, archive.org shows bitcoin.org was an actual hosted site at least by January 31, 2009.  Where was it hosted, and how and to whom was that hosting paid for?

Malmi's first contact with Nakamoto was in 2011 when bitcoin.org was transferred to Malmi.
Malmi did work on Bitcoin in December 2009

Interesting question! I'm also looking forward to hear more on that. But you may find answers to such questions much more rapidly at bitcointalk.org rather than here. It is a everything-around-bitcoin community while here is focused on technical side of bitcoin (& much better).

He must have paid for it with Bitcoins! Ah, wait...

@user97386 the domain was purschased using egold. A somewhat clone of PayPal distributing it s own money pegged to gold. Interesting that Bitcoin was created when the managers of egold were having a hard time being sued for money laundering because their thing didn t allowed to trace who made what with the funds.

How did Nakamoto untraceably pay for registering bitcoin.org?

Nobody knows for certain apart from Nakamoto and the businesses involved.
Nakamoto was (and remains) notably secretive and their true identity is not reliably known† and they no longer communicate with the world using that name in any verifiable manner.
All the businesses involved in the alleged registration process protect the identity and other confidential information associated with their customers. As they should. Therefore the details sought are not public knowledge.

first registered in 2008 ...

That certainly appears to be the case.
The domain registry information currently includes the following information:
Domain Name: BITCOIN.ORG
Registry Domain ID: D153621148-LROR
Registrar WHOIS Server: whois.namecheap.com
Registrar URL: http://www.namecheap.com
Creation Date: 2008-08-18T13:19:55Z
Registrar: NameCheap, Inc.

...via anonymousspeech.com,

The website of AnonymousSpeech.org says

Any inquiries  regarding the identity of our subscribers are ignored. We do not respond to any of them.

We are committed to the privacy of our users, and will absolutely not release any kind of data to any foreign governments.

archive.org shows bitcoin.org was an actual hosted site at least by January 31, 2009. Where was it hosted, and how and to whom was that hosting paid for?

That information is not available.
We know a couple of important things about Nakamoto:

They were extremely protective of the secrecy of their identity.
Though their work was not without flaws, they were competent in the field of online privacy and encryption.

We should therefore not expect to easily find any information they specifically sought to hide from the public.
Nakamoto's main aim was to create a cash system that did not rely on trusting third parties - their aim was not to teach us how to anonymously register DNS domains. This should shape our expectations of available information.

Footnotes
† So far as I know, the people claiming to be Nakamoto have failed to provide proof or have provided evidence subsequently shown to be false. We cannot ask Nakamoto and if we could, they would not an answer if their behaviour is consistent with their past behaviour.

So law enforcement might get it if needed.

@user2284570 and like Al Capone, they would first come to collect taxes from him, considering that he has around 1 million bitcoins! It is for this reason that I believe governments might actually know who he is, he must have made some opsec mistake on the early days somewhere, and the incentive to find them is large.

@CiroSantilli郝海东冠状病六四事件法轮功 Depends. In come countries you don t have to pay anything until you cash out. Also, I learned the domain was purschased using egold. A somewhat clone of PayPal distributing it s own money pegged to gold. Interesting that Bitcoin was created when the managers of egold were having a hard time being sued for money laundering because their thing didn t allowed to trace who made what with the funds.

@user2284570 Yes, not sure about all countries, but UK and US you have to pay capital gains at least I think.

@CiroSantilli郝海东冠状病六四事件法轮功 more exactly, he bought the domain on registrar offerring to pay in egold as well as visa/MasterCard. But nothing states he paid in gold outside the fact his stands seems to favor a gold standard.

@user2284570 Do you have any references for this claim that he paid with egold?

The answer to this is the way domain names are purchased and secured at registrars such as godaddy.com and namecheap.com plus multiple registrar payment methods. For a fee the registrar will hide the true owner and all details of a site and put in a proxy name. You can go to www.internic.net to find out about a domain such as:
Domain Name: BITCOIN.ORG
Registry Domain ID: D153621148-LROR
Registrar WHOIS Server: whois.namecheap.com
Registrar URL: http://www.namecheap.com
Updated Date: 2019-11-24T13:58:35Z
Creation Date: 2008-08-18T13:19:55Z
Registry Expiry Date: 2029-08-18T13:19:55Z
Registrar Registration Expiration Date:
Registrar: NameCheap, Inc.
Registrar IANA ID: 1068
Registrar Abuse Contact Email: abuse@namecheap.com
Registrar Abuse Contact Phone: +1.6613102107
Reseller:
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Registrant Organization: WhoisGuard, Inc.
Registrant State/Province: Panama
Registrant Country: PA
Name Server: DNS1.REGISTRAR-SERVERS.COM
Name Server: DNS2.REGISTRAR-SERVERS.COM
DNSSEC: unsigned

Domain names  can be moved from owner to owner of registrar to registrar around in a highly secure fashion and decentralized fashion. Now that I think about it, a little like coin transfers.

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


text:
What is the data format layout for txindex LevelDB values?
The keys I understand, t + 32-byte hash.
But my problem are the values. I understand from sources such as What are the keys used in the blockchain levelDB (ie what are the key:value pairs)? that the values should encode three values: dat file number, block offset, and tx offset within block.
But I've noticed that each value has a different sizes between 5 and 10 on the first thousand entries, so I'm not sure how to decode the values into those three fields. Are those fields simply 3 varint values?
Here's my Plyvel code that prints out the lengths using plyvel==1.5.1, Bitcoin Core v26.0.0 on Ubuntu 23.10:
#!/usr/bin/env python3

import struct

import plyvel

def decode_varint(data):
    """
    https://github.com/alecalve/python-bitcoin-blockchain-parser/blob/c06f420995b345c9a193c8be6e0916eb70335863/blockchain_parser/utils.py#L41
    """
    assert(len(data) > 0)
    size = int(data[0])
    assert(size <= 255)

    if size < 253:
        return size, 1

    if size == 253:
        format_ = '<H'
    elif size == 254:
        format_ = '<I'
    elif size == 255:
        format_ = '<Q'
    else:
        # Should never be reached
        assert 0, "unknown format_ for size : %s" % size

    size = struct.calcsize(format_)
    return struct.unpack(format_, data[1:size+1])[0], size + 1

ldb = plyvel.DB('/home/ciro/snap/bitcoin-core/common/.bitcoin/indexes/txindex/', compression=None)
i = 0
for key, value in ldb:
    if key[0:1] == b't':
        txid = bytes(reversed(key[1:])).hex()
        print(i)
        print(txid)
        print(len(value))
        print(value.hex(' '))
        value = bytes(reversed(value))
        file, off = decode_varint(value)
        blk_off, off = decode_varint(value[off:])
        tx_off, off = decode_varint(value[off:])
        print((txid, file, blk_off, tx_off))
        print()
        i += 1

but it eventually blows up at:
131344
ec4de461b0dd1350b7596f95c0d7576aa825214d9af0e8c54de567ab0ce70800
7
42 ff c0 43 8b 94 35
Traceback (most recent call last):
  File "/home/ciro/bak/git/bitcoin-strings-with-txids/./tmp.py", line 39, in <module>
    blk_off, off = decode_varint(value[off:])
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/ciro/bak/git/bitcoin-strings-with-txids/./tmp.py", line 29, in decode_varint
    return struct.unpack(format_, data[1:size+1])[0], size + 1
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
struct.error: unpack requires a buffer of 8 bytes

So I wonder if I guessed the format wrong, or if it's just a bug in my code.
Comparing to: https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer I would decode:
42 ff c0 43 8b 94 35

manually as:

42
ff: expect 8 bytes next

c0 43 8b 94 35: only 5 bytes left, blowup

I also tried to inverse value:
value = bytes(reversed(value))

but then it blows up very early, definitely wrong.
I also tried to ignore the error to see if there are others, but there were hundreds them, so something is definitely wrong with my method.
Related:

https://bitcointalk.org/index.php?topic=1068721.0

Update
Given Antoine's answer, I've updated my code to:
#!/usr/bin/env python3

import struct

import plyvel

def decode_varint(data):
    i = 0
    ret = 0
    while True:
        b = data[i]
        ret += b & 0x7F
        if b & 0x80:
            b += 1
        else:
            return (ret, i + 1)
        ret <<= 7
        i += 1

ldb = plyvel.DB('/home/ciro/snap/bitcoin-core/common/.bitcoin/indexes/txindex/', compression=None)
i = 0
nerrs = 0
for key, value in ldb:
    if key[0:1] == b't':
        if i % 1000000 == 0:
            print(i//1000000)
        txid = bytes(reversed(key[1:])).hex()
        print(value.hex(' '))
        total_off = 0
        file, off = decode_varint(value)
        total_off += off
        blk_off, off = decode_varint(value[total_off:])
        total_off += off
        tx_off, off = decode_varint(value[total_off:])
        total_off += off
        assert total_off == len(value)
        print((txid, file, blk_off, tx_off))
        i += 1
print(f'nerrs: {nerrs}')

and all length asserts seem to pass which is promising. However, when I tried to verify the first few values:
93 1a 96 8c e7 74 a7 bb 0a
('d176d4960a78b41971f9d19207b59af6584b16ef323de55e983aec0100000000', 2458, 46347252, 646538)
93 1a aa d0 f0 72 86 90 01
('4d19a5ba6a5455a6d4d46d6999fb0a4a7b29e603fe229cd4f1a34d0300000000', 2458, 89405554, 100353)
93 1e d4 cf 18 82 be 76
('ba75d6ac075959632d9e012f0321c367a54e9f2bde2e2bebce6baa0300000000', 2462, 1386392, 40822)
93 18 a8 96 8e 5a 8a d3 14
('7df98bab9d89fc14d0dec365fa124b3e112017c6b8f56f64cf159e0600000000', 2456, 84248410, 174484)

I didn't find a match between:
bitcoin-core.cli getrawtransaction d176d4960a78b41971f9d19207b59af6584b16ef323de55e983aec0100000000
tail -c+$((46347252 + 646538 - 1)) ~/snap/bitcoin-core/common/.bitcoin/blocks/blk02458.dat  | head -c 2000 | xxd -p | tr -d '\n'

bitcoin-core.cli getrawtransaction 4d19a5ba6a5455a6d4d46d6999fb0a4a7b29e603fe229cd4f1a34d0300000000
tail -c+$((89405554 + 100353 - 1)) ~/snap/bitcoin-core/common/.bitcoin/blocks/blk02458.dat  | head -c 2000 | xxd -p | tr -d '\n'

bitcoin-core.cli getrawtransaction ba75d6ac075959632d9e012f0321c367a54e9f2bde2e2bebce6baa0300000000
tail -c+$((89405554 + 100353 - 1)) ~/snap/bitcoin-core/common/.bitcoin/blocks/blk02462.dat  | head -c 2000 | xxd -p | tr -d '\n'

so either my parsing or my checks are wrong somehow.
I've searched for the bytes that getrawtransactions gave me for d176d4960a78b41971f9d19207b59af6584b16ef323de55e983aec0100000000 using bgrep: https://unix.stackexchange.com/questions/223078/best-way-to-grep-a-big-binary-file/758528#758528 and found it at:
~/snap/bitcoin-core/common/.bitcoin/blocks/blk02586.dat: 02ed92ce

and offset 0x02ed92ce = 49124046, so these would be the expected correct values for this one.

You are confusing the VarInt and CompactSize encoding. CompactSize encoding (also confusingly referred to as "varint" outside Bitcoin Core) is used in the Bitcoin protocol. VarInt encoding is internal to Bitcoin Core and used as a more compact encoding in the internal database.
See this answer for details about the VarInt format:

Variable-length integers: bytes are a MSB base-128 encoding of the number. The high bit in each byte signifies whether another digit follows. To make sure the encoding is one-to-one, one is subtracted from all but the last digit. Thus, the byte sequence a[] with length len, where all but the last byte has bit 128 set, encodes the number:
(a[len-1] & 0x7F) + sum(i=1..len-1, 128^i*((a[len-i-1] & 0x7F)+1))

Thanks for this. I've updated my code on the question, and it does seem to extract 3 integers correctly from every value as expected. However, I was not able to actually find the transactions at those offsets as explained in the question now, I wonder what I'm doing wrong.


text:
Verifying Bitcoin ownership
Suppose Alice has 30 bitcoins from David. Now Alice wants to transfer amount 20 bitcoins to Bob.
Now, Alice creates a transaction with Bob's bitcoin address.
To prove authenticity and integrity, Alice digitally signs the current transaction.
To prove that Alice owns the money, the current transaction includes hash from David's transaction which can be verified by the recipient and other nodes on the network.
As per my understanding, transactions are collected in blocks which are linked to form a block chain. Every node on the network stores the block chain. To verify whether Alice owns the money, one has to verify the bitcoin address of Alice in David's transaction. Now David's transaction can be very old, in older blocks. How this check is done? Is the hash of David's transaction for Alice's ownership checked in every block in the block chain?
Is the ownership verified by going from block to block?
Also what prevents Alice from using David's transaction again and again?

A bitcoin transaction can have 1 or more inputs and 1 or more outputs. Inputs are previous transaction outputs that sent bitcoins, and outputs are instructions on where to send the bitcoins from the inputs. The total value of the outputs cannot exceed the total value of the inputs, and any leftovers (output is less than input) will be taken as a transaction fee by the miner who created the block that verifies the transaction. Also, an output can only ever be used as an input once.
So, in your example, David's 30BTC transaction is the only input, and you need an output of 20BTC to Bob's address. That leaves 10BTC in change. Typically, you would create another output back to yourself. This is called 'change'. So there will be two outputs, 20BTC to Bob and 10BTC to Alice (or maybe slightly less, providing a fee for miners and encouraging them to verify the transaction quickly).
The actual verification is complex, but a simple explanation would be that a verify-er can traverse the entire blockchain from start to finish, picking up every output and discarding outputs as soon as they are used as an input. When he's done, he's got a list of unused outputs that could be used in future transactions. To verify transactions included in the next block, he just has to make sure the transaction has inputs that are on the list, and that there are no other transactions in the new block trying to use the same input.
So, if David's transaction was used as input in the past, it wont be on the list. If Alive tries to be sly and create multiple transactions at the same time that use David's transaction, the miners will only include one of them.
Meanwhile, once you have your list, you don't really need to traverse the blockchain from the beginning again, you just have to keep your list up to date by reading each new block and removing used outputs and adding new unused outputs. That way, you always have a list of valid inputs.


text:
How can one Bitcoin address be associated with mulitple IP addresses?
I'm new to Bitcoin and I'm having trouble understanding the concept of "address". I understand that an address is created when you want to send or receive bitcoins from someone. You create a bitcoin address and you give that address to someone so that he or she can send bitcoin to that address and you'll receive the payment.
However, how can a bitcoin address be associated with multiple IPs? For example: https://blockchain.info/address-relayed-ips/15VjRaDX9zpbA8LVnbrCAFzrVzN7ixHNsC
This bitcoin address is connected with multiple IPs. I know that many bitcoin users advocate that we shouldn't reuse addresses. There is no way that someone else can just "pick up" the address that we just abandoned, since addresses are generated randomly. Then how is it possible that an address can be used in different IPs? Is it because the associated IPs include the IPs from which it has received payments?

A bitcoin address is not based on or tied to a network address, they are completely different.
Think of the Bitcoin address as a bank account number and the IP as a telephone caller ID. When you call your bank from different phones they'll see different caller IDs but you'll give them the same account number each time. They can write down the caller ID if they're spying on you, but that doesn't have anything to do with the account number other than the fact that you yourself are using both.
Likewise an observer can watch you sending transactions to the network from your IP address, and if you use the same Bitcoin address more than once they can see your sending IP address each time (unelss you use Tor...). But that doesn't have anything to do with the Bitcoin address other than the fact that you yourself are using both.

However, according to the link provided, the Bitcoin address is associated with multiple IPs from different parts of the world. Does that mean this address has been used in different parts of the world?

At the bottom of that page (in light grey on white text) it says: "These IP addresses were the first to relay a transaction involving the selected address. It does not necessarily mean they are the transaction's owner."
So the IPs represent the peer on the Bitcoin peer-to-peer network that received and rebroadcast the transaction. The list may relates more to where the largest mining pools are based rather than where the user is based, however in either case the user is probably in the US.


text:
Get input address using VIN txid?
I have written following script to get Vin address from Vin txids.
#!/usr/bin/python
# -*- coding: utf-8 -*-
import requests,json
url="http://asd:asdf@localhost:2332"
payload={}
payload = {"jsonrpc":1,"id":"curltext"}
 txid= "10ff6ff5bdc73d7bb6d711c6896618a05479d061e67f576a0950328c1389035f"
addresses = []

payload["method"]="getrawtransaction"
payload["params"]=[txid,1]
response = requests.post(url,json.dumps(payload))
response =response.json()
response= response["result"]["vin"]

for data in response:
    raw_tx1=data["txid"]
    vout_int=data["vout"]
    payload["params"]=[raw_tx1,1]
    response_ = requests.post(url,json.dumps(payload))
    response_= response_.json()
    data_ =response_["result"]["vout"]
    for item in data_:
        if item["n"] == vout_int:
            json_data ={}
            json_data[item["scriptPubKey"]["addresses"][0]] = item["value"]
            addresses.append(json_data)

print addresses

for some txids i get proper o/p for example:
[{u'MKHWXiX9Xm37jdCM8EzWMWNRJPhuwUxWiN': 50.0},{u'MVTpa2h3DGFWxkcmEkYLv4cYGggVprjjDZ': 300.0}]

but for other its says
    response= response["result"]["vin"]
TypeError: 'NoneType' object has no attribute '__getitem__'

Why is it behaving like this? Isnt it supposed to have uniform output irrespective of txids? If my approach is wrong then how was i getting correct for some tx ids again?

That error means that either response or response['result'] is None which means that getrawtransaction is probably unable to find the transaction id that you are providing.
Before you try to read data from the response, make sure it isn't None and actually has a result.

i guess issue was because i didnt mentionled txindex flag in my .conf file. Now when i put txindex=1 it seems to be working fine


text:
IP Addresses of inbound connections in bitcoin full node (TOR) looking as a localhost (127.0.0.1)
I run bitcoin full node (mynode) through TOR and I see that inbound connections appear only as a localhost with varying ports usually in high range (examples 127.0.0.1:35010, 127.0.0.1:58188, 127.0.0.1:38804, 127.0.0.1:56338).
My config setup for TOR in bitcoin node is:
proxy=127.0.0.1:9050
listen=1
bind=127.0.0.1
onlynet=onion
dnsseed=0
dns=0

What are these inbound connections? Are they nodes of other people or some apps running on my mynode? And if they are nodes of others why are they channeled through my home address and how?

Yeah, it's "some apps running on my mynode" ==> it's the Tor proxy :p

Those are incoming connections coming through the proxy, which have no other possible identifier than coming from localhost (where the proxy daemon is running). The "sending" port number is effectively irrelevant for this situation. If you don't want incoming connections through the proxy, don't configure them to be allowed.


text:
Get Coinbase.com miner fee before sending to another address
I am using coinbase.com php library to send bitcoin to another address. But every-time i am sending bitcoin the fee is shown to me after sending the bitcoin. This is causing me some problem. Is there anyway to get the miner fee for a transaction before I send the amount. Thank you.
**I am using the official PHP library of coinbase.com

Coinbase is notoriously inefficient with their transactions (no batching, no SegWit) and still overcharging on fees. Then they blame Bitcoin. If you depend on Coinbase your service will fail once the fee market picks up again. Also: not your keys, not your bitcoins. Do not keep bitcoin on an exchange. See MtGox and many other examples in history.

All perfectly valid points but not answering the question Jannes....


text:
Importing the keys Issue
I imported the private keys into my wallet and they appear to be added:
This is the result when i run getImportedKeys():
[ECKey{pub HEX=022249de1a0fb3c72fe9284ca449477ef1b0e43dc4245d3137d7d7a57f697f8d1d, isEncrypted=false, isPubKeyOnly=false}, ECKey{pub HEX=039ad0a1c1f63b3d5db4eab32401396f0dae98935825e99381cd3a630092ef1e0f, isEncrypted=false, isPubKeyOnly=false}, ... etc

I resynced  the wallet, but the transactions associated with this keys are not showing up.
From my understanding it can deduce the public keys from the private keys, and look up the transactions associated with those keys. Im using WalletAppKit to create the wallet, everything works okey, the wallet is functional. This is how i initialize the wallet:
    MainContext = context;
    coinreceived = MediaPlayer.create(MainContext, R.raw.received);
    coinsent=MediaPlayer.create(MainContext, R.raw.sent);
    kit = new WalletAppKit(netParams, new File(String.valueOf(context.getFilesDir()+ File.separator + walletFolder))  , "walletappkit-example");

    kit.setDownloadListener(listener);
    kit.setBlockingStartup(false);
    kit.startAsync();

    saveWalletAddress();

Any ideas on how can i solve this? Thanks in advance.

What software is that even?

I forgot to mention, bitcoinj.


text:
How can I increase the routing my 'small' lighting node performs?
I know this question has been asked a lot. However I am not able to grasp the correct approach to address this.
Let me give you the context: I spun up an LND node to start experimenting and understanding the capabilities of this spectacular technology. Put $100 worth of sats in the node and spread it across 4 channels and I was also lucky to have another 5 channels open with me - so I have some outgoing capacity from the channels I have opened and also some inbound capacity from the channels others opened to me. The channels are unbalanced meaning that, for the channels I opened remote balance is 0 and for the channels others opened to me local balance is 0. I know that channels should be balanced to be able to perform routing in both directions in every channel but thought since others have also opened channels to me, I could still route some transactions. Is this a valid assumption?
Base fee is set to 0 and my fee rate is 0.000001 which I believe is cheap to incentivize some routing. For 4 months now fwdinghistory returns nothing. I thought that with this setup I could easily route just a cup of coffee but it seems we are not there yet.
What can I do to reach the point where I actually perform some routing? I don't want to commit more capital to the node until I am confident of what I am doing and how things work. Again the rational behind is that 100$ should suffice to route some coffee buys. I understand that the first thing to do is to try to provide liquidity where liquidity is needed but I simply don't understand how to identify where liquidity is needed.

Look for merchants who accept lightning for payments and open channels with them.

How ?! Is there a methodology like analyzing the graph and the IPs to understand who is a merchant?

One way would be to buy something from the merchant. The invoice they provide you will contain their node id (or it can be recovered from the signature of the invoice).

Some merchant stores will also label their node with an Alias, or have a site online to allow you to open channels with them. see: ln.river.com

If I was trying to solve for the largest number of transactions routed I would be very intentional with which nodes I open channels. Here is a methodology that you could try starting with a fresh node with only $100 in sats in capital and 0 channels opened.

Choose  a consumer facing (custodial) wallet that you have an account with (Wallet of Satoshi, Muun, Kraken, Cash App, etc).

Open a channel to them with the full $100.

Push that full balance to their side of the channel by paying yourself to your account from your node (this could potentially link your node to your IRL identity).

Wait for a new exciting lightning service to go viral on twitter or another internet forum. (this service will likely need inbound liquidity)

Use the $100 balance in your custodial wallet to open a channel to this service's lightning node

You can find their node id by inspecting an invoice.

Wait for funds to flow from [popular wallet] -> [you] -> [new viral service].

It might be advisable to set a low fee at first, as LND biases routes along previously successful routes (although i'm not quite sure if this bias is reset when changing channel fees).

To make a profit from this scheme you'd have to make more money charging routing fees from the source (where funds are coming from) to the sink (where funds are going) than you pay in fees getting this capital online (onchain fees, ln fees, wallet service fees).

This is a very naive scheme which will likely only work for a short duration if at all but should get you started thinking about how to provide routing liquidity to the network.
The main take away should be, "How can I get better at putting my channels between sinks & sources?"


text:
Under what conditions could a change address immediately send the entire balance to a third-party address?
I have a situation where I sent 1 coin to and address I own and my wallet sent the unspent output to a change address but due to a glitch in the wallet software, that change address doesn't show up in my wallet. I did see that change address in my wallet at some point in the past but when I upgraded the wallet, the address was gone. When I look at the unspent transaction, I see that it immediately flushed the entire address to another address that I think I do not own. I do not have my private key and cannot seem to reproduce it from my 24 word BIP32 mnemonic.
Questions:

If I own the private key to the change address, then how could the change address spend my coin without my private key?
If the wallet doesn't identify the change address as being owned by me, does the miner take the balance?

I'm stumped by how and why this happened.
Thanks

What software are you using?

If you look up the receiving addresses involved in blockchain.info, it may help shed some light on what's happened.

Generally, this should not happen. The situations this can happen should be limited to:

bugs in the software
malicious acts by the software

to resolve this you will need to look up the transaction on a block explorer and document all relevant information, including the block height, transaction id, inputs spent, target address, change address and possibly the miner that relayed the block.
armed with this information you then reconfirm in you wallet and doublecheck for deviations, and if necessary contact the developers of the wallet.
if they cannot help, you should at least be able to ask new and more precise questions here afterwards.

It now appears that the wallet code that was meant to create a change address using my seed, was hacked or hard-coded to substitute another address instead and my unspent output was moved to that address. That address was created in 2014 and my seed was created in 2016. I'm told that I am SOL. But I think this is theft and will likely proceed along those lines. Here is the transaction: https://blockchain.info/tx/d4914fa646f07f0b211eda96ab629650e1f7e33c1fb0cabbdf77458407d1a647

I also define that as theft, could you share your story with others to help avoid further thefts? In particular, it would be good to know which wallet software, and what source you downloaded it from.

The wallet is mSigna and somehow unspent coins are sent to a change address not created by your private key. Apparently this has caught others out and they have upgraded the code. But I am SOL.


text:
Blockchain.info receive payments API, bitcoins lost?
I use the Blockchain.info receive payments API. It's all working nice and good, but now I have a payment that doesn't reach my adress. It is unconfirmed for almost 24 hours.
Also, the payment doesn't show in Bitcoin-QT (also not as unconfirmed)
You can see here: https://blockchain.info/address/1J2SpT8wBUsVhP6MBtc5sqJkUMgdfHPSZ4
Normally Blockchain.info pays the miner fee, so I should receive them very quickly.
Are my bitcoins lost in the abyss?

Seems the payment got through after all. Weird, it took more than 24 hours.
So, just wait and keep waiting, in the end, it's all gonna be alright.

In any case, if any payment is unconfirmed for any reason (including being added to a block that gets reorganized away), the bitcoins are not lost: they are still in the sending wallet (though a rescan may be needed if the wallet doesn't realize). Only a valid tx included in the blockchain can move bitcoins from one address to another.


text:
bc.info transactions with no timestamp
The last transaction in blocks 219882, 219888, and 219892 don't have a timestamp.  And by last transaction I mean the last transaction shown in the json file.

219882
219888
219892

I find this to be a bit odd.  Does anyone know why this has occurred?

There is no timestamp field in bitcoin transactions. BC.I timestamps the transaction when it comes to this service for a very first time. You should not use this value, because it can be quite incorrect/irrelevant.
I think that the last transactions in these blocks have not seen by BC.I in "wild" form. BC.I discovered them when they come within a block. So, it is a small bug on BC.I - it does not shows you timestamp for some txs.
Just live with it.

What do you mean by 'wild' form?

Wild = Not in a block


text:
blockchain.info transaction timestamps set into the future
There seem to be some irregularities with Blockchain.info's transaction timestamp (aka Received Time) for a set of blocks.  The transaction times are recorded with unix timestamps well into the future (2017, 2022, 2035, etc..)
For example, here is a transaction in block 237173 with a timestamp of 2035-05-27 00:00:59.
All the blocks that have transactions with a future Received Time are as follows:
237173
237175
237180
237181
237182
237183
237184
237185
237186
237187
237188
237189
237190
237191
237192
237193
237194
237195
237196
237200
237201
237202
237210
237280
237945
237980
238008
238013
238038
238227
239127
240078
241223
260657
260819
1) Are these valid transactions?
2) If they are valid, how can I assign a valid timestamp to these transactions?  Would it be 'fair' to simply assign them the block's timestamp?
3) From what I understand about the Received Time, it represents the time that bc.info sees the transaction, so how can this this timestamp be occurring?  Is it a bug?

A similar (answered) question is available here: http://bitcoin.stackexchange.com/questions/37721/bc-info-transactions-with-no-timestamp

That's also my question, but I don't believe it's the same issue.  That answer is saying bc.info missed the transaction so it couldn't timestamp it.  Here there is a timestamp. Some are close into the future (Aug 2015) and some are very distant into the future (Apr 2078).

Oops, I should have noticed that was your question. Since bc.i's backend is closed source, it seems unlikely (IMO) that you'll get a better answer to this question other than what you already know... that bc.i is a bit buggy....

Np, it just seems like a really odd bug.  Anyway, I at least hope the info above could be useful to others.

They are valid if they are in the best blockchain. 2) Take the timestamp from the actual Bitcoin block (instead of the Blockchain.info web service). 3) No idea, it's probably an idiosyncrasy of Blokchain.info's operations.

1) Are these valid transactions?

Yes

2) If they are valid, how can I assign a valid timestamp to these
  transactions? Would it be 'fair' to simply assign them the block's
  timestamp?

You can do anything. Yesterday I've timestamped them as 1905, today as 2048

3) From what I understand about the Received Time, it represents the
  time that bc.info sees the transaction, so how can this this timestamp
  be occurring? Is it a bug?

Yes.

Why are you allowed to timestamp them far into the past/future?

Transactions do not have timestamp fileld! This is only bc.i point of view

@mrp Who would stop you and how would they stop you? You can put any timestamp on any transaction you want. My understanding is that blockchain.info claims to timestamp them based on when they first saw them, but it seems they sometimes screw that up.

Block and transaction timestamps are unreliable in a peer to peer environment. See similar question here https://bitcointalk.org/index.php?topic=1164293.0
You could have timestamp of block n > timestamp of block n+1. bc.info seems to reporting received time same as block timestamp, which seems to be a bug. I suggest you explore other blockchain apis like blocktrail and tradeblock .

There's no such thing as a transaction time stamp anyway so the point is fairly moot.


text:
Can I sell Bitcoin bought in 2014?
In 2014, my cousin told me about bitcoins. I thought they were pretty cool, so I went to coinbase and bought 10 at the time (I was 14 at the time). Then, my best friends grandparents passed away and I forgot about them ever since.
Now I am 17, and today I logged on and am shocked to see coinbase says my 10 bitcoins are worth $60,000 dollars. How can this be? I am tempted to cash it out but feel this is illegal and the goverment is going to be on me. Should I tell coinbase there is a bug in the system or something? Has anyone had a similar situation?

10 bitcoins are worth $60,000 dollars. How can this be?

Indeed, the price has skyrocketed recently, each bitcoin is worth around $6092.00 USD as of writing this answer, it's not a glitch.

I am tempted to cash it out but feel this is illegal and the goverment is going to be on me.

It's not illegal to sell or buy bitcoins in most countries, see: https://en.m.wikipedia.org/wiki/Legality_of_bitcoin_by_country_or_territory
You should probably just ensure you pay tax on the income.

authors: Ольга Востокова


text:
How to find private key in blockchain.info account?
I have been trying to send some bitcoin from my blockchain.info account but was asked to provide my private key how can I find my private key on blockchain wallet?

Maybe a similar question, and some answers here: https://bitcoin.stackexchange.com/questions/68196/how-to-move-blockchain-info-api-created-wallet-to-be-used-by-bitcoin-core

There is no way to export your private keys directly unless its an imported address that you imported to your wallet.
To get the private keys for your main wallet addresses:

login to blockchain.info.
Click Settings > Security > Backup Recovery Phrase > write down your phrase with exact order to import it later using Electrum wallet.
Download Electrum bitcoin wallet and setup on your computer.
Start Electrum then choose file > new/restore > click next > choose the option "Standard Wallet" > then choose I already have a seed.
Enter the seed phrase you saved from Blockchain.info then click next you can choose a password to protect your wallet.
Now you control your wallet  click addresses tab then choose the address you want right click and choose private key option.

Dont give your private keys to anyone not to lose your coins


text:
Why does the Genesis block appear to have a lower hash than necessary?
The hash of the genesis block of bitcoin has two extra 0 as compared to other block hashes. According to the logic, it should have been the same as they all have the same difficulty. Why is it so? Was any special reason for doing so?

Hash of genesis block :
000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
Hash of block 1 :
00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048
Hash of block 2 :
000000006a625f06636b8bb6ac7b960a8d03705d1ace08b1a19da3fdcc99ddbd

The SHA256 hash algorithm produces what looks exactly like a random number in the range 0 to 2256-1 (1.1579208923731619542357098500869e+77). Each of those values should be equally likely.
So if you produce a large number of these by altering the data to be hashed, you cannot steer the results and most of the results will be a large number.
Some of the results will be a small number and a few will be very small. It is perfectly possible that the first result that is small is also very small - there is nothing impossible or surprising about that.
Since the genesis block had no history, there should be no expectation that the target value was especially precisely calculated to match the exact hashing power available.
Furthermore, I would expect the target would have been high (low difficulty) since there were very few miners (only one?) - The higher the target, the more space there is for a solution to be some orders of magnitude smaller than necessary. If conversely the difficulty was so high that hashes had to be less than 42, there would be no room for a successful hash to be two orders of magnitude smaller than needed.

Why would a higher target mean lower difficulty? Sorry for noobish question.

@anotherDev, suppose the miner's task is to throw a dart at a dartboard blindfolded and score less than some target number. The higher that target number is, the less difficult it is to get a lower score. See https://en.bitcoin.it/wiki/Target and https://en.bitcoin.it/wiki/Difficulty

Related: https://bitcoin.stackexchange.com/a/102416/13866

Ok. I will read them to know more. Thanks.

Bitcoin difficulty is not determined by the "number of zeros", but none the less the Bitcoin genesis block would satisfy a difficulty target substantially higher than might be expected. This doesn't really mean anything in the scheme of how the system operates, it's just a curiosity.


text:
Use BIP39 to generate SSH or TLS keys?
Is it possible to use the same Bip39 mneumonic that generates addresses/keys to generate deterministic key pairs for use outside of cryptocurrency, say in ssh, tls, etc?
I know that bip39 doesn't use RSA and some conversion would need to be done, but I'm just wondering if it's possible.
For the simplest example of what I'm trying to achieve I'd like to convert the derived public/private keys from the table from here: https://iancoleman.io/bip39/ into ssh pairs, as a start.

I just had the same idea before I stumbled upon your question here. Did you fiddle around with ssh-keygen and found a way to make it work?

SSH is a generic protocol within which a user can deploy keys from a variety of algorithms, one of which is ECDSA (same as Bitcoin signatures).
The Ledger hardware wallet even has an application for its devices to perform SSH signatures using keys derived from the same seed used for cryptocurrencies.
TLS also has EC available as an algorithm so there might be a way to use your BIP39 seed for this as well.

right but I can't see (using openssl for example) how to convert the derived pub/priv keys from bip39 to be used in ssh.  do you have an example of how to do this?  for example, taking a private bip39 key and using openssl to generate the private keys?

You can read the manpage for ssh-keygen, which can generate a key pair from a specified key type and input file. You're on your own finding a way to export a bitcoin private key into PEM format so that openssl can import it though.


text:
How many characters of an address do I actually need to verify?
Let's assume I want to verify the receive address on the phone. The recipient confirms the first M and last N characters of the address. How big is the computational effort for an attacker to create a valid address that has the same M characters at the beginning and the same N characters at the end?
What would be a safe M/N?
Is it okay if the recipient doesn't mention if a character is upper or lower case?

How big is the computational effort for an attacker to create a valid address that has the same M characters at the beginning and the same N characters at the end?

It depends on what your attack model is.
If you're worried about an attacker replacing your address with another valid address that matches in a number of places, but is not spendable by the attacker (so they'd just be burned funds), this is easy, regardless of how many characters you check. If this is your concern, you should check all of them, except possibly the last  6, as those are only checksum characters. If everything but the checksum matches, the checksum itself will also match.
If you're only concerned about attackers who replace addresses with others they themselves can spend, it is harder.

In base58 addresses: Every character except the first one makes it 58 times harder for the attacker. Checking any 11 characters would require a nontrivial amount of computation time (264.4 work). At 22 characters, it would be assumed computationally infeasible for anyone (2128.9 work, similar to what cracking a public key itself would need).

If you ignore lower/uppercase, every characters only makes it up to 29 times harder for an attacker. Then 14 characters would require 268.0 work, and 27 characters needs 2131.2.

In bech32(m) addresses: every character except the first 4 requires 32 times more work from the attacker. Around 13 characters here means 265 work, and 26 for 2130. Bech32 addresses are case insensitive.

Note that these computations assume the attacker knows which characters you'll be looking at, which is perhaps the case if you're always going to pick the N first and M last to compare. If you compare random ones, it is significantly harder for attackers, but the computation would depend on the exact strategy used.
For reference, base58 addresses for Bitcoin mainnet start with 1... (P2PKH) or 3... (P2SH). bech32 addresses start with bc1q... (P2WPKH or P2WSH) or bc1p... (P2TR).

How big is the computational effort for an attacker to create a valid address that has the same M characters at the beginning and the same N characters at the end?

It's pretty easy to make addresses with are visually similar to one another, here only targeting the start of the address but there's no particular reason why it couldn't target the end as well.
18eXmgR5Svoqqa6PaYVrKvbH6hvrp5xe3A
18eXmgR5Svoqqa6JXSMmbNaD4Cs5ThcV1P

These examples for P2PKH are both valid, and used bitcoin keys that share 20 characters. They would have taken a number of hours to produce on today's CPUs, which isn't particularly an issue in any attack scenario.

Is it okay if the recipient doesn't mention if a character is upper or lower case?

Lowercase and uppercase are different addresses in p2pkh addresses, so it weakens any partial cross validation. For newer bech32 addresses capitalization is irrelevant and simply doesn't matter.


text:
Creating bech32 address on bitcoin core automatically generate another address on lightning network
my lightning network backend is bitcoind. Interesting when I execute getnewaddress label bech32 another bech32 address is automatically generated. I found it because at the lightning network console pops up a new line [INF] RPCS: [newaddress] addr=xxxxx and it is not the same as the address at bitcoind.
It doesn't happen if I created with another wallet type such as legacy wallet.
So my questions are
1. why another address? what is the purpose of this automative generation?
2. what is the link between these two addresses? does deposit at one affect another in a descrete way?

Which lightning client are you using? c-lightning?

nope, the lightning network. https://github.com/lightningnetwork/lnd

That’s lnd, not the lightning network.

so lighting network includes lnd, c-lightning etc?

LND, C-Lightning, are implementations that both follow the specifications of the lightning network, and so, for the most part can communicate and function together on the same lightning network. It would be possible to: 1. fork LND, change one line, and then claim there is a third implementation on the lightning network. 2. Run a separate lightning network that listens on different ports, that exists on another plane than the lightning network we have today.

@HamiltonWong lnd and c-lightning are both Lightning implementations. You can choose either. It's like you can use Firefox or Chrome to browse the WWW.


text:
What does best block time mean in wallet.dat
I have a wallet.dat file that states:

Best block at time of backup was 42603 (0000000013136bd812212959a15ef0ea0f084ee2c64e2f7f0e127d198f67a37f),
mined on 2010-02-26T00:36:08Z

Does that mean that one of my address mined on that block?  Or is it just referenced with no correlation to my private keys with unspent coins?

may I ask how did you open and saw thr contents of wallet.dat?

I did dumpwallet on bitcoin core.

Its the time the wallet was last synchronized to, it won't know about any transaction changes in or out past this time until it has been loaded again by a synchronized node. It has nothing to do with your transactions specifically.

may I ask how can someone open and see the contents of wallet.dat?

You can’t really. It’s a berkeleydb database without a lot of human readable structure, it’s only meant to be read by machine.

But the original poster hinted he could see the contents: "I have a wallet.dat file that states..."

So even if I add these private keys to another wallet, the balance wont show because i never did full node with bitcoin core?  Because I've checked over 1000 addresses so far and 0.00 :(     I believe that this wallet.dat came from my Guiminer I had on my computer I downloaded in 2011.


text:
Mining Bitcoin heats up my Computer. why?
I am Trying to mining bit coins from last 1 year. but every time i turn on the mining it slows down my computer and heat it up very badly that it eventually stops working some times.
How To get rid of this?
Help Me Please.

Mining uses your computer's computation power - the more it uses, the more yiu're rewarded. If you don't want it to slow down your system, don't do it. Furthermore, Bitcoin cannot be profitably mined on home computer hardware since 2013 or so; you need specialized ASIC-based hardware instead. If you're mining today, it's either an altcoin (which is off topic here), or a scam.

All of the energy that is used in any computation eventually leaves the hardware as thermal energy. Bitcoin mining is an energy intensive computational process, so one of the by-products of it is thermal energy (heat). If you want to stop generating heat, you'll have to stop mining (or figure out how to dissipate the heat more efficiently).
Keep in mind that bitcoin mining is only profitable using specialized ASIC hardware (that generates a lot of heat). Mining bitcoin with your laptop/PC will just use up electricity (and generate heat), without any real chance of doing enough work for you to receive a reward.


text:
How to merge the datadir with .bitcoin directory?
I changed the path of datadir in bitcoin.conf from .bitcoin directory to somewhere else.
Now that I need to backup my blockchain data, I want to have both .bitcoin and blockchain data together.
Assuming all bitcoin-core services are off, How should move the blockchain data properly?
datadir contents:
==== Files ====
anchors.dat
banlist.dat
debug.log
fee_estimates.dat
.lock
mempool.dat
nano.save
peers.dat
settings.json
.swp

==== Folders ====
blocks
chainstate
indexes
wallets

.bitcoin contents:
==== Files ====
anchors.dat
banlist.dat
bitcoin.conf
debug.log
fee_estimates.dat
.lock
mempool.dat
peers.dat
settings.json

==== Folders ====
blocks
chainstate
wallets

Why don't you make a symbolic link from datadir/blocks to .bitcoin/blocks (assuming you are not using Windows)?

@Zenul_Abidin I want to backup on an NTFS external hard drive and I want it all to be together


text:
Blockchain refund
I recently lost funds to a Bitcoin trader CryptoASX based in the UK (London) which turned out to be a fraudulent trader. Just today (Tuesday 19 October 2021) I received a phone call from an organisation calling themselves Blockchain Refund, also based in the UK.
Blockchain refund has is offering to refund my losses plus. To get my refund I need to set up an "Atomic Wallet" and provide them with a screenshot of 17% of the refund amount, before they will release the funds. They will send me the refund.
Does this sound legitimate?

This looks like a double scam. I wouldn't do what "Blockchain Refund" say.

Does this answer your question? Is there a 'BTC Refund Department'? -- What you describe is 100% a scam.  On this Q&A website you can see similar questions from many people scammed exactly this way.

see also https://www.fca.org.uk/news/warnings/blockchain-ltd-blockchain-refund-department-clone-fca-registered-emd-agent

That is definitely another scam.

People who fall for scams are a hot commodity and their details are being sold to other scammers because they are much more likely to fall for it again.
You should ask yourself why would a random organization call you out of nowhere and offer you free money, how does that make any sense?


text:
I have what I believe are my address and password - don't know what wallet from 2017
I have what appears to be a GUID and a password.  But no recollection what service I used of if I even purchased / transferred or made a transaction with them back in 2017.  Any way to check to see if I have anything in here and retrieve it?  My current BTC is on a platform I use regularly, this was prior to me setting up my current process last year...  Any advice?

Unfortunately I don't know how to help you with so little information. If I were you I'd search my emails for a service I could have used at the time, then try their restoration process if any, and contact their customer service (if any). Can't help more than that.

That would be a very old Blockchain.info wallet, they're the only ones using a GUID for the identifier.

Thanks - it worked.  Balance was ZERO.  Much appreciated your help with this found losing lottery ticket however!!!  Dreams live on.


text:
Can we have multiple possible nonce making same number of leading zeroes in the hash?
Is it possible to have different nonce which are satisfying the same condition of having let's say 4 leading zeroes in the hash?
Is it possible that one node suggests 89123 nonce and other node suggests 30221 nonce, both leading to a valid (but different hashes) leading to 4 zeroes?
Does nonce calculation always start from 0 or 1 up to infinity?

Nonce is 32 bits and can't get anywhere near infinity. And extranonce (in coinbase), which is what modern miners actually need to vary to find a winning block, although larger is still finite.

Is it possible that one node suggests 89123 nonce and other node suggests 30221 nonce, both leading to a valid (but different hashes) leading to 4 zeroes?

This is only possible if something has gone horribly wrong. Either these two nodes are cooperating or they aren't cooperating. Let's consider the two cases:

If the two nodes aren't cooperating, why would they mine blocks that differ only in the nonce? That would mean both nodes were trying to deliver the block reward and the transaction fees to the same wallet even though they're not cooperating. That makes no sense.

If the two nodes are cooperating, why would they both be working on the same block? That would require them to divide the nonce space, which is extraordinarily inefficient because realistic miners go through all nonces in a tiny fraction of a second. Every sensible form of cooperative mining ensures that no two nodes are working on the same block so each node can use the full nonce space without duplicating work.

So this should never happen. If two blocks for the same height get mined at about the same time, they will be blocks that differ in more than just the nonce.

Yes, I believe there can be many nonce values that produce a hash whose numeric value is less than the current target. Particularly as other data can be varied too. The probability obviously depends on the target.
The order in which a miner tries nonce values is not prescribed but is any order chosen by the miner.
See also

How does solving a block work in relation to the first letter/number after the 0's?


text:
Homework problem on Blockchain and Merkle trees

This is a question from a stanford course(http://cs251crypto.stanford.edu/18au-cs251/hw/hw1.pdf).
I think that Alice needs to send all the k blocks (containing the transactions) to Bob so that Bob can hash them one by one to ensure that next block is in chain. As the block Bob has, contains last transaction's hash, he can verify with that. But in that case, he can simply see the transaction, and merkle tree don't come into picture, so k data is not used and size of 1 block is also not provided in question. Am I missing something. Also, Alice can send the Merkle proof (the log(n) number of extra hashes along with hash of the transaction) to prove that the transaction is present in a block (comparing the net hash with Merkle root). But, the problem is that Bob contains only current block header, but the original transaction is in the chain n blocks back. Now if Alice provides only the header, bob can't know that they are not edited. Is there any other way, he can send some information which will ensure that Alice has not tampered with the info?

The question parameters restated:

Bob only has latest header stored locally
Alice's payment is k blocks before current head
n tx's per block

Alice needs to prove two things:

1) Her payment is committed to header chain_height-k
2) Current header at chain_height builds on chain linked to header at chain_height-k

Merkle-Proof
You need to construct the payment TX merkle-proof (merkle path only) for the header block at height-k. This proves your transaction was confirmed in a block.

The merkle tree has a height of log2(256)=8. The size of this proof is
  (8*2+1)*32 Bytes.

Strong-Chain Proof
You also need to prove that miners performed POW on top of the block which contained your transaction. This can be proven by providing headers which are linked together, although the problem does not give you any figures on those header sizes.

You could assume Bitcoin headers of fixed size 80B, so (k+1)*80 Bytes.

Note that only the headers are required for this POW proof, because the light client cannot verify whether the TX's committed to these headers are valid or not.
This chain provides the proof that the strong-chain builds on the block which includes your transaction.

But if only header of block is provided, how can Bob confirm that header are not modified, as there is no whole block, so he cannot find its hash to match it against the hash provided in next block.

Also I think height of merkel tree will be log_2(256)=8, and why is the factor of 2 taken?

Only the header at height n is committed to the next highest block (n+1). The transactions of that block are already committed to n, through the marke root.

Apologies, sloppy math on my part, you are correct it is log_2(256). I have amended the answer.


text:
CHECKSIG description from the wiki
I have been using the Bitcoin Wiki to know more about the CHECKSIG, and the graphic which is shown there.
This question will be rather long, but it would already help me a lot if you could just read my description and just let me know if I am correct or wrong.
My question is regarding how to calculate the hash (from the serialized transaction) which is then signed.
Generally the way I understand it, we first create a new raw transaction with input and outputs with pubKeyScripts.
Then to create the signature, we copy the pubKeyScript from the transaction we are spending into the SigScript at the input of our new transaction. Then we serialize the new transaction, appending to the string the hashType (SIGHASH_ALL/SIGHASH_NONE, etc.) and then create the signature for that string.
Then we clear the SigScript and put the public key and signature into the SigScript and have a signed transaction. When the bitcoin network validates the transaction it will create the serialized transaction string in a smiliar manner and check that the signature delivered in the SigScript of the new transaction is for the calculated string (and from the correct private key).
First of all is this correct? And if so, why is the pubKeyScript of the transaction we are spending used when calculating the serialized string of the new transaction we want to sign?
The new transaction is already referncing the ID of the spending transaction in the input of the new one. Therefore I cannot see why it is useful to also temporary copy the pubKeyScript of the spending transaction into the SigScript of the new transaction to make the signature?
Furthermore, I was trying to look in the source code from Bitcoin to find out what happens. I am not a programmer, escpecially not in C++. But I found out that the signature is checked here:
https://github.com/bitcoin/bitcoin/blob/48efbdbe986355bd2478f0fdd366b20952fbf30a/src/script/interpreter.cpp#L847
The referehnce to "scriptCode" in line 838, which is used as argument to checker.CheckSig() seems to contain only the pubKeyScript from the transaction being spend (without input, outputs, etc. from the new transaction?).
I was not able to find out where exactly in the source code the function checker.CheckSig() is defined.
But does checker.CheckSig calculate the serialized transaction as I have described above by adding the scriptCode into the SigScript and serialize it? If so do you know where in the source code that happens?
I hope you can give me some inputs to it. Thank you!

Minor quibble: usually it's written scriptSig and scriptPubKey, not the other way around.

Also, we had a discussion about this recently in Bitcoin Lounge (prompted by your other question, actually) http://chat.stackexchange.com/transcript/message/24348979#24348979 The upshot is that the FindAndDelete call in the sourcecode you linked is not the only place the signature is removed before signing.

Nice pointing out in the Bitcoin Lounge the serialization in the code! https://github.com/bitcoin/bitcoin/blob/48efbdbe986355bd2478f0fdd366b20952fbf30a/src/script/interpreter.cpp#L1003 So the scriptPubKey from the transaction referenced in the input of the new (spending) transaction is clearly used and probably the signing works as shown in the figure. I just wonder why that Script is used in the serialization?

The purpose of signatures is to 'capture' some data about the transaction - it's outputs, and so on. Signers have control over some of it, using SIGHASH flags, but some of it is enforced by the network.
Remember that anyone verifying your signatures needs to know what you're asserting in your signature, and how to reproduce the same hash for ECDSA.
When producing the signature, and verifying one, SignatureHash() is called on every input, because each input has it's own signatures.
For each input, the transaction reserialized with a CTransactionSignatureSerializer which makes the input-specific modifications to the transaction. It will null inputs/outputs given some SIGHASH flags, and also requires that the scriptPubKey of the previous transaction is included.
It seems you were enquiring partly about this. The reason for capturing this through a hash is it means the signature can't be used on other transactions. A signature is only valid for a given input, and all the requirements of its scriptPubKey.
Hence, you will find that services which verify signatures need to have the scriptPubKey of the transaction being signed for.
Edit: Actually, more specifically, what is included as the script while signing is any script starting from the last OP_CODESEPARATOR, or from the beginning of the output script. So if the script contains OP_CODESEPARATOR, only a part of the output script is signed.
One point where you appear confused is this:

Then we clear the SigScript and put the public key and signature into the SigScript and have a signed transaction

This is not correct - the serialized form is forgotten once the hash is produced. Signatures are put into different transaction instance.
checker.CheckSig() code - Note that it calls the SignatureHash() to produce the hash, and then VerifySignature() calls pubkey.Verify(sighash, vchSig) which is the actual call to ECDSA.
So, most of what you're looking for verification-wise is at the bottom of interpreter.cpp, but also check out interpreter.h for the interfaces.

Thanks for the answer. I still don't understand why the scriptPubKey of previous transaction is included for the signature. The input already contains the transaction-hash and index to the previous output being spend. What is then the benefit of including the scriptPubKey from that previous transaction-output in the signature? The signature can only be used for transactions containing exactly that specific transaction-hash referenced in the input. And the scriptPubKey is typically the same for all outputs to a same bitcoin address (dup hash160 "bitcoin-address" equalverify checksig)

Hi, I've updated my answer (see the edit). Not clear on benefits, but the data included in this part of the hashed transaction can sometimes be a subset of the scriptPubKey, if OP_CODESEPARATOR is used. There are varying reports as to whether its useful feature to have, it's rarely used. Let me know if this answers things for you!


text:
Transaction priority
I'm testing some functionality on the testnet and I'm having problems with the transactions priority.
According to the technical info, a transaction that has not enough priority should have a fee of 0.00001 BTC/kb (1000 Satoshi), but when I try to broadcast my transaction using a RPC call to my local full node, I get an insufficient priority error:
{u'message': u'66: insufficient priority', u'code': -26}

For example, the following transaction has 3 inputs and 2 outputs:
01000000039233cdbb26e926993a8658f1f26b9afc3677e3715c46c10196ad87072b7b88ae000000008a4730440220353cf2638228b64a3e77f37c4b870a8ff4b743e6d34f16a72e5f022505c7c0850220203a00f1489f113d52da891b4d9553f7c469b91a7196350fdb0e295dc6f8f8df0141049da517c9760c05c7af7fdf973d2206add57cff3fbff03488115f667503fab36e6182ffc8eb3ee693885daace3682804ec9476a3f691097631268e6dbcc5b5877ffffffff68a1afda2dec62ad1db346b093a7b418c2ae207dcc0867dad18bd38c5188c845000000008a47304402205fcb79f89500f2fbbdb558f0fc8ea6a5da48e33cf5296bc36d3f09960a68e58f02200c24f823057510f9d68c0a0c59d52615c1d2a7772dc4105e24fe5562b95d93c30141049da517c9760c05c7af7fdf973d2206add57cff3fbff03488115f667503fab36e6182ffc8eb3ee693885daace3682804ec9476a3f691097631268e6dbcc5b5877ffffffff92b877bac70d96e7901afeb0e4281a9c7eb54983b4918bb57a23fd4d2402b037000000008b483045022100efafead31c56a1fbede2af24d551d22e8d811b96881c96dc294ffafe36cdf140022060b356e06b8f96515c529bab9c18f3e1b162774ea83f012cd80667e2c88a59340141049da517c9760c05c7af7fdf973d2206add57cff3fbff03488115f667503fab36e6182ffc8eb3ee693885daace3682804ec9476a3f691097631268e6dbcc5b5877ffffffff02f82a0000000000001976a914b0acf50f8479ec5913e222610e073c1f54c1b01d88acb80b0000000000001976a914b0acf50f8479ec5913e222610e073c1f54c1b01d88ac00000000

what according to bitcoinfees will have a size of:
148 * 3 + 34 * 2 + 10 = 522 bytes

and it also has a transaction fee of 0.00001 bitcoins, but trying to broadcast it will raise the error shown above.
Does anyone knows what could I've been doing wrong?

What version of Bitcoin Core is your full node running?  The minimum fees were different in earlier versions.

Bitcoin Core Daemon version v0.11.2.0-g7e27892

I'm thinking that maybe it could be because of bitcoin dust. Does any output of less than 0.01 BTC require a fee of 0.00001? I mean, if I'm building a transaction with three inputs, two of them of less than 0.01 BTC, and a total size of less than 1KB, would it need 2*0.00001 BTC because of the two small inputs?

At this point I think the best way to try to understand it might be to single-step the source code, either mentally or with a debugger.

I've found what was wrong. It seems that technical info is not up to date to the current Bitcoin Core version (0.11.2.0). Since version 0.11 (12 July 2015) the minimum relay fee is 5 times bigger (from 1000 Satoshi to 5000) so the transaction has not enough fees to be relayed.
Here you could find a discussion about the topic.


text:
Multibit notification
I have  a blockchain.info account and I would like to move my wallet from the web interface to the multibit client.
However, I need that once an incoming transaction have been confirmed I need to call  web service to update a remote database.
Is this possible to do this without modify the multibit code?
I have some experience in Java but this seems beyhon my current skill.
In case I can evaluate other client.
Thanks in advance for any help

As MultiBit HD is targeted for end users it does not have any external API.
Have a look at the WalletTool in the bitcoinj examples module (the Bitcoin network code MultiBit uses).
It gives you a command line interface into bitcoin confirmations.
It's much simpler than the MultiBit HD code so will be much easier to tweak to do what you want.


text:
How do I revoke a multisig transaction?
Let's say that I am using 2 of 3 multisig. I know how to use signrawtransaction and sendrawtransaction to send the funds if at least 2 of the parties have agreed on the transaction, but I don't know how to revoke it and send the funds back to the first person.
How do I do that?

You simply can't 'revoke' transactions. If the output defines a 2-of-3 restriction, 2 of the 3 keys must sign the transaction spending it. If no two parties will agree to sign a transaction spending the output, the money is simply lost.


text:
What kind of privacy does Taproot give bitcoin?
I understand that confidential transactions hide the amounts sent and received. But what does the new taproot privacy technology hide for bitcoin?

Taproot replaces having the script (say, for a smartcontract) written in the tx itself. It uses the MAST scheme to make it so that the redeem script only needs to validate whatever is in the MAST structure, not have the whole contract code, evaluate it and release the coins. (I'm not sure if I'm technically accurate here, I'm not a developer)
It enhances privacy because every tx (be it a smartcontract or not) will look the same. So the privacy benefit is that no one can see that a given tx you sent is actually part of a multi-sig contract, for example. See more here

Taproot allows inputs to hide the fact that there is a script specifying a contract. If sufficient parties involved in that contract agree and cooperatively spend the Bitcoin, that input looks just like any other input, including ones that do not have contracts and have only one person.
This helps privacy as the conditions of a contract are hidden. This also makes such transactions smaller which will save on fees.

replace "all parties" with "sufficient parties".   E.g. a script could have a 2 of 3 threshold at the root.

What privacy benefit does this bring an average p2p transaction? I could imagine some kind of OnChain / CoinJoin "mixing", but participants would have to collaborate first and prepare the transaction first.


text:
Which crypto currency exchanges are using segwit (bc1) addresses for its users?
Are any of the cryptocurrency exchanges using native segwit (bc1) addresses for any of its users?

As of November 2017, only Electrum wallet and blockchain.info are major services which support bech32 address format. A number of services use P2SH wrapped segwit scripts which is easier for backwards compatibility for the moment. This is expected due to the bech32 BIP (BIP 173) not being formalised at this point in time.

So do you recommend not to use bech32 addresses at the moment as they are not backwards compatible?

I'd suggest that services show the bech32 encoding first, and a legacy P2SH encapsulated version for those that don't support it yet. It's the only way that adoption will happen, otherwise you end up with a chicken and egg problem.

How does a legacy P2SH encapsulated version look?

It's indistinguishable from any other P2SH address until spending.


text:
Is it possible to determine the total amount of timelocked Bitcoin?
Now that is possible to lock funds until a certain date (https://coinb.in/#newTimeLocked). How to calculate how many of all bitcoin in existence is locked until a certain date? Any service that does this?

No, it is not possible. Tools like this use P2SH, which means the script which locks the output isn't visible until it has been spent. You can determine how much might be locked (total P2SH outputs for which no script is known) and how much isn't (total non-P2SH outputs), but you can't tell much more than that.


text:
Blockchain.info not sending my IPN to my website
Ok, so I have set up my blockchain.info API. But when I send a payment to the address given, it doesnt send the data. I use the exact same settings and callback in the testing, and it works amazingly. The thing is, blockchain.info doesn't even send my IPN. I know this because my first code is to insert a json format of all $_GET parameters into a database. Any fix?

Is blockchain not sending, or is your script not adding it to the database? You can figure out which is which by running tcpdump.

Blockchain is not sending. Any get parameter that reaches the callback url, is automatically added to a database named "test". So if i went and just put callback.php?g=fds, I would get the get parameter in json format in my database. But after 15 confirmations, still nothing

That doesn't eliminate, for example,  the possibility that a firewall blocked the callback.

But any attempt to visit the site is logged, and I get nothing :\


text:
Blockchain Receive Payments API Not Working
I want to accept payments with the Blockchain Receive Payments API (https://blockchain.info/api/api_receive) but I can't seem to figure out how to work it. I cannot test it too much because there is a minimum amount of BTC that can be sent to the account for it to work and I just ran out from testing because there is no destination for the address but that's another story- I just need to know that it should work. This is what I have so far:
callback.php
$secret = "testSecret";
if (isset($_GET['secret'])) {
if ($_GET['secret'] != $secret) {
    die("Invalid secret");
} else {
    define("HOST", "localhost");
    define("USER", "root");
    define("PASSWORD", "DBPASS");
    define("DATABASE", "xeon.io");
    $mysqli = new mysqli(HOST, USER, PASSWORD, DATABASE);
    $query = "INSERT INTO invoices (item_id, price_in_btc, bought_by, deliver_to, time) VALUES ('2', '001', '1', '1', '0')";
        if ($mysqli->query($query)) {
            echo "*ok*";
        } else {
            die("ERROR!!!!1");
        }
    }
} else {
    die("Blank secret");
}

receive.php
$secret = 'testSecret';
$my_address = '1339LGRGE44QMLYa4hTuyAsbKVjVAGXwHW';
$my_callback_url = 'http://example.com/pay?secret='.$secret;
$root_url = 'https://blockchain.info/api/receive';
$parameters = 'method=create&address=' . $my_address .'&callback='.     urlencode($my_callback_url);
$response = file_get_contents($root_url . '?' . $parameters);
$object = json_decode($response);
echo 'Send Payment To : ' . $object->input_address;

Generating new accounts works just fine but that's not the problem.
The test callback on their site works but when I actually test it, nothing gets written to the database and the BTC isn't returned to the original account nor sent to the destination account.
I basically just want to know if I am doing anything wrong with the above code.
Thanks for the help :)

I investigated and solved that (solution included + some debugging) http://bitcoin.stackexchange.com/questions/51980/php-blockchain-api-callback-not-working/52006#52006

Not an expert, but have I have an ecommerce site that relies on blockchain's API and the error log I have looked at seems to indicate that cloud flare is preventing the return of the info that I'm looking to populate my stores db (just checking balances, etc).
Are there error logs that you've looked at and do they confirm that cloud flare is not the issue?  Seems like it plagues everybody using their API for basic functions.


text:
Blockchain - How can I cancel my blockchain transaction, unconfirmed after +1 day
I am using blockchain.info.
I have made a bitcoin transaction of 4.79 BTC to the address 1DWaEfPbcKQvjMi9D9eNMrVRQzWiSLVvaS. (exchanger)
You can see the transaction at https://blockchain.info/tx/92f565e23499437ed4d54bc946a044c56353c4d1f512cf514b40a31e49292732
I have paid a 0.0001 BTC fee but it has been almost +24 hours and it still shows "Unconfirmed".
Network Propagation 1% - 18 Nodes - (Very Poor) - Why is so poor the network propagation, what;s to do?
What could be the error? Also, more importantly, how do I cancel the unconfirmed transaction and get back my coins?


text:
How to transfer bitcoins from blockchain.info?
I want to transfer bitcoins from blockchain but I don't know how. I have a bither and I want to transfer it there. How to transfer bitcoins from blockchain.info to bither?

Have you tried sending them to your bither wallet?

Blockchain.info also has more than one service. Are you using a mobile wallet, or browser wallet?


text:
Callbacks using blockchain.info's API
I'm trying to accept bitcoin payments on my website using blockchain.info's API. However, I'm confused with their callback.
I've read through their callback, but how would I know if the transaction was successful or not ?

The callback lets you know the payment has been recieved. The confirmations are also included in the callback

When a payment is received blockchain.info will notify the callback
  URL passed using the create method. The parameters will be supplied in
  a http GET request. The callback url is limited to 255 characters in
  length.
Parameters

value The value of the payment received in satoshi. Divide by    100000000 to get the value in BTC.
input_address The bitcoin address that received the transaction.
confirmations The number of confirmations of this transaction.
{Custom Parameters} Any parameters included in the callback URL will be passed back to the callback URL in the notification.
transaction_hash The transaction hash.
input_transaction_hash The original paying in hash before forwarding.
destination_address The destination bitcoin address. Check this matches your address.

A double spend occurs when a malicious user spends the same BTC twice.
  A payment that initial appears successful could be reversed at a later
  date. This is counteracted by waiting for the transaction to be
  included in the blockchain and reaching a number of confirmations. 6
  confirmations is generally considered safe for high value
  transactions.
Validate the transaction confirmations in the callback script by
  checking $_GET['confirmations'] parameter. It is recommended you
  acknowledge the transaction at zero confirmations but only trust the
  transaction after one confirmation. For example, if purchasing a
  product, we would show the order as successful at zero confirmations,
  but only ship the product when 6 or more confirmations are reached.
  See the PHP demo callback.php for an example.

sourced from: https://blockchain.info/api/api_receive

Alright, after some thinking, I finally understood how will I use the callback. Blockchain's API will only send a callback if there has been a transaction. What you need to track here is, that the amount the user sends should be equal to what you've requested.
Let's take a scenario:

I sell an online product worth $5 and use blockchain’s payment receiving API to receive the money.
The user sends an amount less than $5 (suppose $0.05), we then get a callback and assume that the transaction was successful. However, the user paid less amount that he requested. Therefore, we need to keep track of the amount and verify it with the original amount. If both the amount matches, then only you should proceed further.


text:
What are the main technical hurdles to implementing UTXO commitments?
Commits of the UTXO set in the block header would enable more secure lightweight clients and caps on the number of blocks that need to be downloaded and validated in the Initial Blockchain Download, which is vitally important for Bitcoin's longevity and scalability, but I have been told UTXO commits are a very technically challenging change in Bitcoin's design.
What are main technical challenges in implementation of UTXO commitments, and what are the proposed solutions for them?

How is this different than checkpoints? CS isn't my forté

A UTXO commitment is validated by all of the proof of work that was built on top of it.

The main bottleneck of committing to a UTXO merkle root is that it's I/O and CPU heavy to create and verify. As of today the serialized UTXO set is around 1GB and it contains almost 34000000 entries and it keeps growing. This means that a naive implementation would have to hash at least that amount of data per block plus the intermediate nodes to construct a merkle tree. This is O(n) complexity and it is generally considered poor performance. It is possible to use caching optimizations but that would use more RAM.
One possible alternative are UTXO differences that each block introduces. It works by committing a merkle root with all the UTXOs that were spent in the current block and another root that lists all the added UTXOs. For an SPV client this could work as a fraud proof, where it is possible to show that a specific output was spent on a specific height (although it is already possible to show it using ordinary transactions).
So to sum up, a full UTXO merkle root commitments are really useful but cannot be used due to poor scaling.

How long does it take to calculate a new UTXO merkle root?

Not sure but you need to hash about 2x34 million entries. You can try the gettxoutsetinfo rpc command to get a very rough idea (the hash_serialized is the hash of the data, not a UTXO merkle tree).


text:
What method does My Wallet use to encode messages in the blockchain?
What kind of protocol does My Wallet use?

Messages are stored in a database at blockchain.info (so that text should probably be changed). For a while it did use the blockchain for storing messages but this was changed after concerns from a few of the core developers.
Concerns were expressed by Matt Corallo here

Oh god, thats awful...that is quite possibly the worst way to
  implement messages in terms of network load...

and by Gavin Andresen here.

Yes, please don't create lots of unspendable scriptPubKeys. There are
  more prunable ways of embedding messages into transactions. And there
  are even better ways of associating messages with transactions, so
  only people involved with the transaction can read the message (if
  that's desired).

Here is the message that implementation was changed back to using a centralized database.

Since a few developers have expressed concern I've changed the notes
  back to the centralised database for now. I still think there are many
  use cases where you might want to contact the owner of an address
  without needing to know an email etc, a decentralised way to do this
  would be great.


text:
What is a Stratum "mining.set_difficulty" command for?
On the Stratum protocol the server may issue the following notification:
{ "id": null, "method": "mining.set_difficulty", "params": [2]}

What is this difficulty used for? from my understanding the the difficulty is sent with the mining job as an encoded difficulty.
Source:
https://slushpool.com/help/manual/stratum-protocol

The command is telling the miner not to send shares below the requested difficulty. If they were to send every difficulty 1 share for example, many pieces of hardware would be attempting to send hundreds of thousands of results a second. It’s simply flood control, and the only reason to send block shares at all (that are too low of a difficulty to be a block) is to prove to the remote stratum server that you’re doing work worth paying.
Many pools clamp at a lower bound of many tens of thousands of difficulty as of 2017, and many pieces of hardware aren’t even able to produce blocks with a lower difficulty than that. The miner really only needs to send share proofs every few minutes at most for the remote pool to have a reasonable confidence that they are mining at a particular speed for payout purposes.

thank you! so just to clarify the command is used to submit share to the pool and the difficulty sent with the job command is the actual target to successfully mine the block?

It’s a control message sent by the server at any time to control what the client is allowed to send in the future.

sorry i meant control the submission of shares.

Maybe not a good place to ask a "subquestion", but really for newbies there is no a lot of documentation around the place. @eponymous Do you know how to calculate target from difficulty you get form the pool for litecoin (is there difference related with calculating target comparing with bitcoin)?

There's not much documentation on this sort of stuff other than going and reading the code, the number of people with experience using Stratum could fit on a bus. The Litecoin difficulty calculation is entirely different, they hash with SHA2 before doing the scrypt rounds. Best reading their source code to find out in detail how that works.

So what does the 2 mean? ie “params”: [2] .. I’ve seen 8192 used as well. That’s a big difference.