The SPV system is not something that "keeps miners in check". The SPV system is a cryptographically secure way to know that a given transaction is part of a given block chain.
I never said that SPV was to "keep miners in check". You are completely misunderstanding me. Fraud proofs are necessary to have a cryptogrpahically secure way to know that a transaction is part of a given blockchain AND that the transaction is valid. Yes, merkle trees ensure that a transaction is part of the blockchain. But nothing currently exist to prove that a transaction is valid without having to have the full transaction history. The only way that a transaction can be fully validated is to know the transactions that it spends from, and then the transactions those spend from, etc. In that respect, it is working, and it is working correctly. Wallets like electrum work that way as far as I understand.
No, it does not currently work, and it is not how Electrum works at all. All that Electrum can do is know for certain that a transaction is included in a block. It must trust that the Electrum servers that it has connected to have actually verified the transaction. However if your Electrum wallet were to be connected to malicious Electrum servers, they could serve you invalid transactions which you would not know are invalid. Said transaction can be included as part of a block; the merkle root would be correct and the PoW of the block would be valid. BUT the block would contain an invalid transaction. For full nodes, this block would be entirely invalid and discarded. But we are talking about malicious Electrum servers here. So those malicious servers TELL YOU that the invalid transaction is actually valid, and so you accept it. There is no way for you to prove that the transaction is valid or invalid, Electrum simply does not have the data to fully verify the transaction. But we still have met all of the criteria that you wanted: the transaction is included in the merkle root and the block's PoW is valid. The big thing that you are missing is that the block includes an invalid transaction, and SPV wallets have no way of knowing whether the transaction is valid or not. Fraud proofs are required to prove that all of the transactions in a block are valid, and currently they do not exist nor is there a known way to make such proofs. Just because a block has a valid PoW does not mean that all transactions in the block are valid. Just because they are included in the merkle root does not mean that all transactions in the block are valid. There is more to a valid block than just the merkle root and the PoW.
Edit: It's not worth my time to argue this with you. You clearly don't understand how Bitcoin or SPV wallets work. To my ignore list you go. |
|
|
|
Is there any way to force a sync? to make sure it has done one?
You can check if it is synced by clicking the green circle in the bottom right hand corner. This will bring up the network information. If you do not see a green circle, it will be either red or two arrows in a circle. If you see the red circle, you are disconnected from the network. The two arrows in a circle mean that you are currently syncing. In the network information, you should see how many blocks you are synced up to. Make sure that matches what you see elsewhere on block explorers. |
|
|
|
I tried again, a couple times.
i see it appear for a split second as a peer then it goes away.
This is what I see in the log: 2018-02-04 19:00:29 Added connection to 71.13.92.62:4829 peer=53
2018-02-04 19:00:29 connection from 71.13.92.62:4829 accepted
2018-02-04 19:00:29 socket recv error Connection reset by peer (104)
2018-02-04 19:00:29 disconnecting peer=53
2018-02-04 19:00:29 Cleared nodestate for peer=53
This means that the disconnection is happening either on your machine or somewhere in between your machine and mine. I suspect it may be your ISP. You could also try reinstalling Bitcoin Core but I don't think that will do much. I'm using: addnode 73.191.37.221:8333 onetry ... my understanding is that will try to connect once, if it can't it doesn't retain it as a peer to keep trying later.
That's correct. |
|
|
|
|
It should find the transactions automatically. If it does not, either you are not synced, or the transactions were not broadcast/did not propagate well.
|
|
|
|
It appears not, It looks as though it starts a new debug.log every time you start, so I lost the one where it actually started happening.
If the log is larger than 10 MB, it will truncate it at 10 MB. I tried connecting to your node. No sale. Mine is 71.13.92.62
Can you try again? I enabled more verbose logging on my node so I can see what's actually going on (I forgot to enable this earlier). I can connect to it via telnet
Interesting.. Edit: Connecting with telnet does not necessarily mean that your node should be able to connect. Your ISP maybe doing some packet inspection and dropping the packets when it detects that it is related to Bitcoin, but letting packets for telnet through. |
|
|
|
Here's the log since I restarted after it did manage to sync this morning (at that time it had 3 outbound and it had been running for a week). Then I stopped, moved old debug.log to backup and restarted. It's been several hours and still no outbound connections. I did stop it once in here and removed peers.dat and restarted. That was about an hour ago. http://snyderworld.org/misc/debug.logDo you have any logs of when this began happening? Try connecting to my node: 73.191.37.221 |
|
|
|
I've been wondering if the problem was caused by a recent Windows upgrade which seems to have messed around with its firewall.
It's possible that changes to Windows Defender has caused some issues. IIRC Windows Defender will scan your network traffic for anything malicious and it may be confusing Bitcoin traffic for malicious traffic and block it thus causing connection loss. |
|
|
|
|
Can you post the entirety of your debug.log file?
|
|
|
|
Ah, that's interesting. When you contrast that with Satoshi's November 2008 e-mail, where he clearly explained how 100 MB blocks were no problem, and how users would use SPV clients ; and when you see that Hal Finey was the one pushing for the 1 MB limit according to some, we now see that Hal Finey finally took power over Satoshi. Hal Finey is writing here exactly the same objection that Satoshi already replied to in November 2008: "of course we don't send all transactions to all users".
Satoshi never had any doubts about the scaling non-problem from the beginning. Most users simply didn't need the block chain, and that's exactly why he introduced the SPV possibility with the Merkle tree - otherwise there's no need for a Merkle tree structure in Bitcoin ! The very single only reason Satoshi invented the ordering of the blocks in a Merkle tree, is that this allows SPV. If blocks are to be used as a whole, you can simply calculate a single hash of the entire block. Nowhere else do you need any Merkle tree. The Merkle tree is a way to have a minimal number of steps of verification of presence of a piece of data in a block, and really becomes useful only when blocks are very large.
Otherwise you could even resort to a sub-list, that is, a block is a linear list of transactions, and to each transaction corresponds a hash, that can itself be included in a hashed linked list of "hash blocks" all the way to the block header, containing the hash of the last "hash header". The problem is that this list goes as N, when N is the number of transactions in a block. A Merkle tree does the same, but the depth goes as log2(N). This becomes a significant thing when N becomes very large, that is, when blocks become very big. For 1MB blocks, with some 2000 transactions in it, this is not yet very significant. If, in order to check that a given transaction T is in a given block, you need to get that famous "linked list" with 2000 entries, to see that your transaction T was indeed, in the K-th entry of those 2000 entries, that's still very feasible. However, for a block of 100 MB, looking in the list of 200 000 entries, or looking in a path of the Merkle tree, only 18 steps deep, is a hell of a difference.
So from the very start, Satoshi designed bitcoin as a very big block system, of which only mining nodes need to have the full data burden, and of which all other users use SPV and connect to one of these nodes.
The SPV system that satoshi described involves fraud proofs, which are proofs that miners did not commit fraud. However we have no such thing today. From the paper (emphasis mine): While network nodes can verify
transactions for themselves, the simplified method can be fooled by an attacker's fabricated
transactions for as long as the attacker can continue to overpower the network. One strategy to
protect against this would be to accept alerts from network nodes when they detect an invalid
block, prompting the user's software to download the full block and alerted transactions to
confirm the inconsistency
Satoshi realizes that SPV is not secure, and that some method must be implemented in order for SPV nodes to know that they are not being defrauded, e.g. by full nodes giving them some alert. But the Bitcoin network does not support such a thing, so Satoshi's "SPV vision" does not work until such proofs can be made and be provably sound (i.e. you can't fake a proof). |
|
|
|
When they are ships the device? Buyed since 1 February 2018
What they are waiting for?
They are frequently out of stock. They are waiting for more devices to be made so that they can ship. Also, it's been 3 days, don't be so impatient. |
|
|
|
Right, but in the example they were talking about block sizes over 1MB, which as I understand it is a hard limit.
The paper is specifically talking about raising the block size limit with a hard fork. They are going with the argument that miners might be opposed to such a hard fork and users not. So the solution to that is for miners to implement a soft limit after such a hard fork goes through. Also, is there anything to stop everyone from connecting to just one "master-node" on the network, thus making all transactions just one hop to anyone else? I presume this master-node would need enough BTC to handle the liquidity of everyone, but that is theoretically possible.
No, nothing stops people from doing that. But likewise, nothing is stopping people from bypassing that "master-node" and directly connecting to the person they wish to transact with. Do you know if there's a more recent version of the Lightning Network white paper? The latest I've found is version 0.5.9.2 dated January 14, 2016.
There are not versions of the paper itself, but there is a much more detailed specification of the lightning network available here: https://github.com/lightningnetwork/lightning-rfc/.That specification is what implementors are using to actually implement software for the Lightning Network. |
|
|
|
... and I'm a little concerned. Of course I could be misunderstanding things,
but there are several references to soft forks being needed:
A lot has changed with LN's design since the paper was published. And, what is the status of these required soft forks?
However, Lightning Network’s bidirectional micropayment channel requires
the malleability soft-fork described in Appendix A to enable near-infinite scalability
while mitigating risks of intermediate node default.
The Lightning Network uses a SIGHASH_NOINPUT transaction to
spend from this 2-of-2 Funding Transaction output, as it is necessary to
spend from a transaction for which the signatures are not yet exchanged.
SIGHASH_NOINPUT, implemented using a soft-fork, ensures transactions
can be spent from before it is signed by all parties, as transactions would
need to be signed to get a transaction ID without new sighash flags.
Transaction malleability has been resolved with segwit which has activated on Bitcoin. Mark Freidenbach has proposed that Sequence Numbers can be en-
forcible via a relative block maturity of the parent transaction via a
soft-fork[12]. This would allow some basic ability to ensure some form
of relative block confirmation time lock on the spending script.[/i][/b]
Relative lock times have been soft forked into Bitcoin with OP_CHECKSEQUENCEVERIFY. These are the only two soft forks that are necessary for LN to work on Bitcoin, and both have activated. And then it goes on to say that the block size will need to be increased anyway!
It will, or perhaps there will be more improvements which shrink the size of transactions. LN is not the end all be all solution for Bitcoin transaction capacity, but it certainly will provide a huge boost. And the solution to this makes no sense to me:
To mitigate timelock spam vulnerabilities, non-miner and miners’ con-
sensus rules may also differ if the miners’ consensus rules are more restrictive.
Non-miners may accept blocks over 1MB, while miners may have different
soft-caps on block sizes. If a block size is above that cap, then that is viewed
as an invalid block by other miners, but not by non-miners. The miners will
only build the chain on blocks which are valid according to the agreed-upon
soft-cap. This permits miners to agree on raising the block size limit with-
out requiring frequent hard-forks from clients, so long as the amount raised
by miners does not go over the clients’ hard limit. This mitigates the risk
of mass expiry of transactions at once. All transactions which are not re-
deemed via Exercise Settlement (ES) may have a very high fee attached, and
miners may use a consensus rule whereby those transactions are exempted
from the soft-cap, making it very likely the correct transactions will enter
the blockchain.
So my question is, how can you accept blocks that are not accepted by the miners?
What they are describing is the soft limit on block sizes. It is not invalid to create a block that is less than say, 500 kB. However the miners may collude and decide that they won't mine any blocks larger than 500 kB. This does not break consensus rules and all non-mining full node will still accept blocks larger than 500 kB. Just the miners won't produce a block larger than 500 kB and if they see one, they will reject it thus it won't go into the blockchain. This is effectively a miner enforced soft fork. |
|
|
|
1. Can't the thief just try to unlock it by "bruteforcing" the pincode?
Not really. There's a delay between PIN entries which means that a brute force will take a significant amount of time. Furthermore, you can use the passphrases option to further hide your coins; without the correct passphrase, the correct private keys cannot be derived. 2. If I restore my btc on a new nano ledger s, how does it know all the receiving addresses by just having the word seed?
If I understand correctly the nano ledger s will use a different receiving address for every incoming bitcoin transaction.
So it has to have a way to know about all those addresses somehow, but how?
The mnemonic follows the BIP 39 specification to encode a seed value. That seed value uses BIP 32 to derive all of the private keys used by your wallet. Thus the seed holds all of the information that is necessary to reconstruct the private keys for your wallet. Does it rely on any manufactureres service for keeping track on this?
No. 3. What if this happens in say 10 years.. Let's assume the nano ledger S devices are not available anymore and the manufacturere went bankrupt -> No support.
Can I still recover my btc without a nano ledger s device somehow??
Yes. You just need any wallet software that follows the BIP 39 and BIP 32 specifications. These are publicly documented and well specified. Even if such software does not exist, you could write or hire someone to write software that follows the specs. 4. Can the nano ledger S be used with anything else than chrome apps? It sounds like a broken solution to only have apps that rely on google chrome.
Isn't there any application that can use it natively?
Yes. any wallet software which supports the Ledger Nano S can be used. libraries for interacting with it are publicly available so wallet software can just use those. An example of one is Electrum. |
|
|
|
I'm sorry that your not familiar with Linux version 0.2.0. It had encryption for the private key, not the wallet, it was a option that you could use. If anyone is familiar with it can you tell me what type is was. There has to be someone that does remember it. Please help !!!!
I took a look through the Bitcoin 0.2.0 source code and there is no mention of encryption at all whatsoever. The Bitcoin software has never had support for encrypting individual private keys. You are either using some other software or you are mistaken. What does your "encrypted private key" look like? |
|
|
|
You are awesome. Thanks for taking time and explain each parts.
I highly suggest that you read Bitcoin.org's documentation on the raw transaction format as that is basically what you are being given by the stratum protocol. All it is giving you is the entire coinbase transaction with some parts missing that the miner needs to fill out. Those are the nonce and extra nonce which are part of the coinbase. Coinbase1
----------------
Header | 01000000010000000000000000000000000000000000000000000000000000000000000000fffff fff
This is not a header. This consists of 4 different fields. The first 4 bytes are the transaction version number, the next byte is the number of inputs. The next 32 bytes are the transaction id of the transaction the input spends from. The 4 bytes after that are the index of the output that is being spent. In a coinbase transaction, the previous txid must be all 0's, and the output index must be 0xffffffff. Length | 35 (<= this is 53 decimal length counts till signature part  )Yes, that is the length. It is the length of the scriptSig, which in a coinbase transaction, is known as the coinbase. Height | 0371bb07
The first byte is a length specifier. The next 3 bytes are the block height. This is pursuant to BIP 34 | ffffffff (<= is this separator between tx in and tx out ?)
No, this is not a separator. It is the sequence number. Every input has a 4 byte sequence number. end | 00000000
That's the transaction lock time, not "end". |
|
|
|
|
Wallet encryption was not introduced until Bitcoin 0.4.0. Your wallet is not encrypted if it was made earlier than that unless you upgraded to Bitcoin 0.4.0 and upgraded your wallet too.
|
|
|
|
Bitcoin Core 0.15 didn't allow me to symlink my wallet.dat anymore, which is why I switched to symlinking chainstate. Any idea why it's a bad idea (or a link to the discussion?)? Assume that I trust my computer, if I wouldn't trust it, I wouldn't run it, and if it gets compromised, my wallet gets stolen with or without symlinks.
The wallet.dat file is a database file. When it is opened as a database, new temporary files are actually created in the same folder as the wallet.dat file. These temporary files are required in order to have the wallet be properly opened. In the even of an unclean shutdown, those temporary files are required in order to properly open the database again. However when you symlink the wallet.dat file, those temporary database files are actually created in the folder where the symlink is, not the folder containing the actual wallet.dat file itself. So if the wallet.dat file were to be moved or accessed in some way without those temporary database files that are in a completely separate folder, wallet corruption can occur and funds can be lost. Symlinking can also cause some other problems that could lead to corrupted wallet files and losing funds, so we decided to disable symlinking. Note that being able to symlink your wallet.dat file was never an intended feature. Some discussion about this can be found here: https://github.com/bitcoin/bitcoin/pull/10885#issuecomment-329717802 |
|
|
|
|
Bitcoin Core does not have the capability to store information about addresses. The reason for this is twofold: on the technical level, addresses do not exist. They do not exist in the protocol. Secondly, having an address index would require a lot of space and extra code that few people would ever use.
Because Bitcoin Core does not maintain an address index, you cannot get any information about just an arbitrary address. You could use some other software which uses Bitcoin Core as a backend in order to construct such a database that does have this information. But Bitcoin Core itself does not have that capability.
|
|
|
|
1. In second part of coinbase ckpool has extradata ckpool and signature /solo.ckpool.org/
hex : 0a 636b706f6f6c (this converts to ckpool) 11 2f736f6c6f2e636b706f6f6c2e6f72672f (this converts to /solo.ckpool.org/)
Q: ckpool is 6 bytes, why its length is set to 0a ?
These aren't actually length specifiers but rather just straight unicode text. The coinbase part of a coinbase transaction can contain basically anything it wants (except that it must begin with the block height and be less than 100 bytes) that does not have to conform to any particular serialization rules. So What this really represents is a newline (0a is newline) followed by ckpool and then another unicode separator and then /solo.ckpool.org/ 2. If I want to generate all reward into single wallet address (cScriptPubKey), below pseudo code serialized as per protocol for coinbase 2 is correct ?
I think its should be either 0xffffffff or cCoinbaseValue (coinbasevalue is serialized value returned in getblocktemplate response)
var txOut = cExtraData + cSignature + "ffffffff" + cCoinbaseValue + cScriptPubKey + 0.ToString("x8") + cCommitment + cLockout;
No, this is incorrect. This contains more data than should be in a transaction output. What you have is some combination of the input data and the output data. This is actually the second half of the coinbase transaction which includes all of the outputs and part of the input data. The only things in a transaction output are the value and scriptPubKey. So you should only have cCoinbaseValue and cScriptPubKey. 0337a3954a (<= what value is this?)
This is actually two values. The 03 specifies the number of outputs. There are 3 outputs. The rest of that is part of the value. 00000000 (<= if above part is reward value, what is this ?)
This is part of the value. It should be combined with the last 4 bytes of the previous value as the full structure is a 64 bit integer. The full thing is 37a3954a00000000. This is the little endian encoding of the value (which is what Bitcoin uses). The value in decimal is 1251320631 satoshis. 17a9144ab4b2aa35879fe47e6a16ea783494f9dcf615b78772ddc0 (I assume this is where the reward goes)
Only part of this is the output script. That is 17a9144ab4b2aa35879fe47e6a16ea783494f9dcf615b787. The 72ddc0 is part of the next thing. 0000000000
This is the part of the last 3 bytes of the previous thing which is the value of the next output. The value of this is 72ddc00000000000 which is 12639602 satoshis. 1976a914f4cbe6c6bb3a8535c963169c22963d3a20e7686988ac0 (and 0.5% fee goes here ?)
Only the 1976a914f4cbe6c6bb3a8535c963169c22963d3a20e7686988ac part is the scriptPubKey. This output is for the fee. The last 0 is part of the next thing. 00000000000000
This (with the previous trailing 0) is the value of the last output, which is 0 satoshis (yes that is allowed). You are also missing a 0 which you have included as part of the next thing, but that is actually part of this one. 0266a24aa21a9ed99acb686178a3404d59c5f4521ccebf9cb523a337b0c05abc8d3ec375e39af7f 00000000 (this is witness provided in getbloctemplate with lock)
Excluding the first 0 and the last 4 zero bytes, this is the scriptPubKey of the last output. It is an OP_RETURN output that commits the witness hashes of the block. The last 4 bytes are the lock time. |
|
|
|
As title states, is the checksum for bc1 adresses the same as for 1.. / 3.. adresses? It seems that it isn't supported by sites like theseThey are not the same. In fact, bc1 addresses use a completely new encoding scheme known as bech32. This is specified in BIP 173[/quote] and designed specifically for Segwit. Bech32 addresses and Base58 addresses are completely incompatible with each other.
How can i verify myself manually if a bc1 adress is valid?
Not really. Is it actually any different?
Yes, they are very different. Instead of a checksum based on the hash of the data, it is a BCH-like error correcting code. This lets it both detect errors and tell you where they are, as well as correcting some of them (if there are fewer errors than a certain threshold). |
|
|
|
|
Show Posts
