Bitcoin Forum
November 17, 2018, 07:54:24 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 ... 547 »
521  Bitcoin / Bitcoin Technical Support / Re: Bitcoin Core 0.15.1 re-d/l ? on: February 07, 2018, 04:31:45 PM
The 'bitcoind' app is 'bitcoin daemon'? What exactly does that do?
Yes.

It does everything that Bitcoin Core's GUI does but without a GUI. it's meant for people running headless servers or who just don't like GUIs.

And- do I need to open bitcoin core every time before opening Armory? Thanks for your reply-
Yes.
522  Bitcoin / Development & Technical Discussion / Re: Understanding transactions (testnet) on: February 07, 2018, 04:29:50 PM
I've looked through the scripting part and tried to understand it as good as possible, but it still doesn't make quite sense to me why you'd do something like this?

Can you come up with a usecase?
It's testnet, people experiment with random things on testnet. It's possible that the transaction was a mistake and a bug in some software produced it. But it happened on testnet and that's fine.

It's also possible that someone is experimenting and learning how scripts work, so they created that transaction. It's testnet and that's okay, that's what testnet is for.

It really does not matter why such a script exists; you just need to know that it does and such scripts can exist so you need to be able to handle them.
523  Bitcoin / Development & Technical Discussion / Re: Generate coinbase from to send to miner (ckpool source code question) on: February 07, 2018, 04:26:04 PM
Thanks, Below is the request received from pool, so if you check first header above which looks like big endian has previous hash as is.
It is not big endian.

I do not think that this is exactly what your miner received from the pool. I think what you are seeing is based on an internal representation of the data which makes it appear to be different than what it actually is.

So bloc header has previous hash flipped in 32 bit chunk ?
That is what is being displayed, but that is not what it actually has to be in the block header.

But as per documentation it doesn't say so.
Because your miner is displaying that information incorrectly.

prev_hash: da780ff935f3917ed99a7b616cb98ebb3104b3fa000b7acd0000000000000000
The correct block hash is f90f78da7e91f335617b9ad9bb8eb96cfab30431cd7a0b000000000000000000. You will notice that if you byteswap this so that it is actually in big endian, the block hash becomes 0000000000000000000b7acd3104b3fa6cb98ebbd99a7b6135f3917eda780ff9 which is an actual block that you look up on a block explorer or node. Looking up what your miner is displaying in both its original form and byteswapped form results in not being able to find such a block.
524  Bitcoin / Development & Technical Discussion / Re: Bitcoin Core & Milestones on: February 07, 2018, 04:15:52 PM
The new issues and PRs are related to critical-sh bugs found in RC1 and RC2. The final version will be released when those bugs are resolved and no new ones are found with the next RC.
525  Bitcoin / Bitcoin Technical Support / Re: Bitcoin Core 0.15.1: RPC call to re-read config file? on: February 07, 2018, 04:14:32 PM
Quote
New rpc command "reloadconfig" to dynamically update configuration parameters (Issue #309). Command line parameters will not be overridden. Notice that many core parameters are used only during startup.

But such command does not seem to exists.
Because that Pull Request was not merged.


Why do I need it? - it seems that adding an entry wallet=mynewwallet.dat will create a new mynewwallet.dat if it does not exists when the program starts.
This is good since I want to be able to dynamically add wallets in a multi-wallet mode. but the server needs to restart entirely which is bad for me.

Is there an option I missed in Bitcoin Core RPC to reload the conf file? My version is 0.15.1 on Windows 10.
No, there is not.

Reloading the bitcoin.conf file comes with a lot of potential consequences that can result in strange or broken behavior. There are many things that have to happen at startup in order for some things to work.

What you want is unrelated to the bitcoin.conf file. There is no need to let the bitcoin.conf file be reloaded in order to allow for wallets to by dynamically loaded and unloaded. Instead of jumping to that extreme, we can just add a feature that lets you dynamically load and unload wallets. In fact, there is an open pull request for exactly that: http://github.com/bitcoin/bitcoin/pull/10740. It is not merged yet so this behavior does not currently exist in Bitcoin Core. But hopefully in the next major release, it will.
526  Bitcoin / Development & Technical Discussion / Re: Generate coinbase from to send to miner (ckpool source code question) on: February 07, 2018, 05:33:17 AM
cgminer log shows stratum header constructed as below
20000000da780ff935f3917ed99a7b616cb98ebb3104b3fa000b7acd0000000000000000854e4bd db4eeb7c1841b651ceb26f4d12116bfcc2c41ed18220fd701571914ba5a6fdbfa176c2146000000 00

Look at version, time, difficulty part. Shouldn't it be flipped as big endian ?
No, everything in Bitcoin is serialized as little endian. Actually, this is serialized as big endian, but in kind of a strange way. It seems like it is being printed out with each 4 byte chunk (32 bit integer length) in big endian, which also means that the merkle root and previous block hash fields are messed up. But this is not the actual block header it is hashing.

And at the calculation of midsate its flipping all 4 bytes.. meaning 00000020f90f78da7e91f335617b9ad9bb8eb96cfab30431cd7a0b000000000000000000dd4b4e8 5c1b7eeb41c651b84d1f426ebccbf162118ed412c01d70f22
This is the correct block header. Everything is in little endian as it should be. This is what the block header should look like.

When submitblock is called, what should be sent as block header ?
The second one.
527  Bitcoin / Development & Technical Discussion / Re: Bitcoin's earliest developers on: February 06, 2018, 04:47:03 PM
Sipa is the only person still working on Bitcoin on that list, and is therefore the longest serving programmer in Bitcoin development. So Sipa has probably contributed to Bitcoin development more than anyone else.
I'm pretty sure that sipa was only added to that list so that he could help migrate/maintain the bitcoin-dev mailing list. Development had moved from sourceforge to github in 2010 before the sourceforge repo was abandoned.

IIRC all of Wladimir, Pieter, Greg, Gavin, Jeff, and Matt all got involved within months of each other in 2010-2011. I think Wladimir is actually the longest contributing active contributor.

The person who contributed the longest and is still somewhat active is actually Dooglus.



A good place to find this kind of history is to scroll through the git log in reverse (i.e. earliest commit first).
528  Bitcoin / Development & Technical Discussion / Re: Bitcoind - Getbalance command on: February 06, 2018, 04:02:00 PM
You can't do it with bitcoind/Bitcoin Core. In order to find the balance of an address, an address index is required. But maintaining an address index is expensive and not that useful since the node does not need it to operate, so one is not maintained. There is no code in Bitcoin Core to build such an address index.

It is important to note that addresses and balances do not exist on a technical level. It requires significant computation to produce balances for all addresses, and requires a lot of additional storage space to store that data.
529  Bitcoin / Development & Technical Discussion / Re: Why the fuck did Satoshi implement the 1 MB blocksize limit? on: February 06, 2018, 05:40:02 AM
This thread has devolved into a lot of trolling, mudslinging, and flaming. Thus it shall be locked.
530  Alternate cryptocurrencies / Altcoin Discussion / Re: private network question on: February 06, 2018, 05:39:22 AM
Private network based on what? Bitcoin does not have a "genesis Json file"
531  Bitcoin / Development & Technical Discussion / Re: A few questions about bitcoin's codebase on: February 06, 2018, 01:48:25 AM
Hello all, i've been a developer for the past couple of years and i would like to jump onto the blockchain coding paradigms, i've downloaded the first satoshi client's code (0.1) and there's this overview http://fonstavka.com/index.php?topic=41718.40 that i would like to follow but there's a couple of missing files (i presume) mainly, i can't find the init.cpp file,
It doesn't exist in 0.1.0. A lot of stuff has changed since then, and it really is not worth your time to read through the original source code. So much has changed that whatever you learn is not applicable to the latest source code. You should instead try to learn and understand Bitcoin Core's latest source code. Keep in mind that the project has grown significantly since 0.1.0 and is much more complex.

anyway, i would like to ask a couple of questions to any developer that delved into the code out there, first, does anyone out there know of a chatting room/forum for people like myself?
You can try the #bitcoin, #bitcoin-dev, and #bitcoin-core-dev channels on Freenode's IRC.

Also, does anyone know of any guides/overviews/write ups that explain any parts of the code of any version of the bitcoin client? or is there any other altcoins that are similar to follow but a little easier? Any books that helped you go through the code?
I don't know of any recent ones that are accurate. But it isn't all that hard to follow the code. It is fairly well commented and the names of things are self explanatory. You can start with src/bitcoind.cpp where the main function is for bitcoind and then follow along from there. Knowing how to use grep to find things is also very useful.

and what cryptography knowledge books did you make use of?
Bitcoin does not actually use that much cryptography. You just need to understand some basics, like what a hash function is and what digital signatures are. That's about it.
532  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.
533  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.
534  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.
535  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.
536  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.
537  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:

Code:
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.
538  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.
539  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 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.
540  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.
http://snyderworld.org/misc/debug.log
Do you have any logs of when this began happening?

Try connecting to my node: 73.191.37.221
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 ... 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!