Bitcoin Forum
November 17, 2018, 08:06:48 PM *
News: Latest Bitcoin Core release: 0.17.0 [Torrent].
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 [28] 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 ... 547 »
541  Bitcoin / Bitcoin Technical Support / Re: bitcoin core not making outbound connections or taking hours to make 2 or 3 outb on: February 04, 2018, 06:23:38 PM
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.
542  Bitcoin / Bitcoin Technical Support / Re: bitcoin core not making outbound connections or taking hours to make 2 or 3 outb on: February 04, 2018, 06:15:30 PM
Can you post the entirety of your debug.log file?
543  Bitcoin / Development & Technical Discussion / Re: Why the fuck did Satoshi implement the 1 MB blocksize limit? on: February 04, 2018, 06:14:18 PM
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
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).
544  Bitcoin / Project Development / Re: Digital Bitbox (a hardware wallet) Discussion on: February 04, 2018, 05:56:25 PM
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.
545  Bitcoin / Development & Technical Discussion / Re: So I just read the LN white paper... on: February 04, 2018, 01:17:19 AM
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 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: specification is what implementors are using to actually implement software for the Lightning Network.
546  Bitcoin / Development & Technical Discussion / Re: So I just read the LN white paper... on: February 04, 2018, 12:09:25 AM
... 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.
547  Bitcoin / Alternative clients / Re: How does a Ledger Nano S work? on: February 03, 2018, 09:19:51 PM
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?

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.
548  Bitcoin / Development & Technical Discussion / Re: What type of encryption did the early Bitcoin use to encrypt the key Feb 2010 on: February 03, 2018, 08:52:19 PM
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?
549  Bitcoin / Development & Technical Discussion / Re: Generate coinbase from to send to miner (ckpool source code question) on: February 03, 2018, 08:46:45 PM
You are awesome. Thanks for taking time and explain each parts.
I highly suggest that you read'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.

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 Huh )
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".
550  Bitcoin / Development & Technical Discussion / Re: What type of encryption did the early Bitcoin use to encrypt the key Feb 2010 on: February 03, 2018, 05:36:54 PM
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.
551  Bitcoin / Bitcoin Technical Support / Re: Does Core work fine on Xubuntu and Lubuntu? on: February 03, 2018, 05:35:12 PM
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:
552  Bitcoin / Bitcoin Technical Support / Re: Bitcoind get address info on: February 03, 2018, 05:25:49 PM
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.
553  Bitcoin / Development & Technical Discussion / Re: Generate coinbase from to send to miner (ckpool source code question) on: February 03, 2018, 05:29:59 AM
1. In second part of coinbase ckpool has extradata ckpool and signature /
hex : 0a 636b706f6f6c (this converts to ckpool) 11 2f736f6c6f2e636b706f6f6c2e6f72672f (this converts to /

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 /

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.

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.

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.
554  Bitcoin / Bitcoin Technical Support / Re: Is the encoding of bc1 adresses the same as 1../ 3.. adresses? on: February 03, 2018, 01:05:22 AM
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 these
They 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).
555  Bitcoin / Armory / Re: How much hardware is needed to run a full node? on: February 03, 2018, 01:00:54 AM
Bitcoin Core and Armory are fairly memory intensive. You're going to have a hard time with anything less than 4 GB of RAM, especially with running both software.
556  Bitcoin / Bitcoin Technical Support / Re: SECONDARY TRANSACTIONS HAVE HIGH TRANS FEE, BUT PRIMARY VERY LOW. on: February 02, 2018, 06:07:59 PM
This transaction spends from an unconfirmed transaction and which also spends from another unconfirmed transaction. This one cannot confirm until those unconfirmed ones confirm too.

Because these spend from an unconfirmed transaction, they cannot confirm until the unconfirmed one does too.
557  Bitcoin / Bitcoin Technical Support / Re: Help with multi signature wallets on: February 02, 2018, 05:05:17 PM
Do you mean multisig for the 2 factor authentication or just normal multisig to have multiple parties required for a transaction to be validly signed?

For the former, you can use Electrum with the TrustedCoin service. BitGo also offers a similar thing.

For the latter, you can use basically any modern wallet software. This includes Electrum, Armory, Bitcoin Core, etc.
558  Bitcoin / Development & Technical Discussion / Re: Suspicious: bitcoin core syncing way fast on: February 01, 2018, 03:58:30 PM
IIRC, somewhere around core version ~0.13, there was some kind of rewrite of some of the sourcecode with a result of a speedup while syncing....
That happened at version 0.10. Since 0.10, syncing the blockchain has gotten much faster. Of course there are performance improvements that happen with every major version that make syncing the blockchain faster and faster.
559  Bitcoin / Bitcoin Technical Support / Re: What is Node and or Masternodes??? on: February 01, 2018, 03:53:08 PM
Nodes are machines that are part of a network. In the case of Bitcoin, it means machines that are part of Bitcoin's peer to peer network. They receive and send blocks and transactions.

Nodes can be broken down into several types: full, pruned, and SPV. A full node is one which receives all transactions and blocks, fully verifies each one, and relays them. It also stores the full blockchain. Full nodes can serve the entire blockchain to anyone who wants it.

Pruned nodes are like full nodes except they don't store the full blockchain. They still verify and receive all blocks and transactions and relays them.

SPV nodes are nodes which only receive blocks and transactions, and not necessarily all of them. They typically only receive ones which pertain to their wallet. SPV nodes are incapable of fully validating all blocks and transactions and do not relay blocks or transactions unless it originated from that node.

Masternodes are a certain type of node for altcoins that have special abilities. Bitcoin does not have masternodes.
560  Bitcoin / Armory / Re: I'm really depressed need help on: February 01, 2018, 03:50:26 PM
Post your log files.

Try using 0.96.4 RC3, available here:
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 [28] 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 ... 547 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!