Bitcoin Forum
February 18, 2019, 09:17:12 AM *
News: Latest Bitcoin Core release: 0.17.1 [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 79 80 81 82 ... 551 »
621  Bitcoin / Development & Technical Discussion / Re: About possibility to Sign messages in Segwit address in future on: February 05, 2018, 04:38:12 PM
My doubt, regarding signing in segwit address is if this is a "bug" and will soon be corrected, or is it an abandoned feature?
It is neither a bug nor an abandoned feature. It is just that we are still working on creating a more generalized signing scheme that lets people sign with things like P2SH addresses (e.g. sign with a multisig address). There is simply no standard yet for signing with such scripts or with Segwit.

Note that you don't actually sign with an address. You sign with a public-private keypair and your wallet interprets it as an address. Your wallet could just as easily interpret it as a segwit address. We are working on creating something that actually specifies the address type, and more generally, allows signing with scripts.
622  Other / Archival / Re: [LN] closing a payment channel on: February 05, 2018, 03:48:55 PM
I.E. Closing channel means posting latest ln tx on blockchain and waiting time-lock to expire.
The two parties in the channel can close the channel cooperatively and create a special closing transaction which does not have a time lock. In a unilateral close, you would have to wait for the timelock, but that should only be reserved for special circumstances where the other party is not available for a cooperative close.
623  Bitcoin / Bitcoin Technical Support / Re: bitcoind testnet solo mining on: February 05, 2018, 05:26:35 AM
With bitcoin-cli or in bitcoin-qt's debug console, use the generate and setgenerate commands.
624  Bitcoin / Development & Technical Discussion / Re: Why the fuck did Satoshi implement the 1 MB blocksize limit? on: February 04, 2018, 11:06:16 PM
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.
625  Bitcoin / Electrum / Re: Electrum on: February 04, 2018, 09:10:50 PM
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.
626  Bitcoin / Bitcoin Technical Support / Re: bitcoin core not making outbound connections or taking hours to make 2 or 3 outb on: February 04, 2018, 07:07:44 PM
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 peer=53
2018-02-04 19:00:29 connection from 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 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.
627  Bitcoin / Electrum / Re: Electrum on: February 04, 2018, 06:57:51 PM
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.
628  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:53:44 PM
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
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

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.
629  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:35:44 PM
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.
Do you have any logs of when this began happening?

Try connecting to my node:
630  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.
631  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?
632  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).
633  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.
634  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.
635  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.
636  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.
637  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?
638  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".
639  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.
640  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:
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 79 80 81 82 ... 551 » is not available or authorized for sale. Do not believe any fake listings.
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!