Hey, thanks all for the help.
And what type of blocks are available? i though the only "block" is a transaction of bitcoins (?)
In Bitcoin, there is only one type of block. Blocks are a collection of transactions, not a transaction themselves. |
|
|
|
So, there is only 1 Blockchain, and all nodes connect to this?
The blockchain is not something that nodes connect to. I thought that every node download a copy of the blockchain
Yes, every node downloads a copy of the same blockchain. Everyone's copy of the blockchain updates basically at the same time as they receive new blocks. Blocks are transmitted in the same way that transactions are. When a node downloads the blockchain, it does not do so from a central server either. Once it establishes connections to other nodes, it begins requesting blocks from all of the nodes that it is connected. When it receives a block, it will validate each block according to the built in consensus rules before it accepts the block. If conflicting blocks are received, the node will choose the block that corresponds to the blockchain with the most work. |
|
|
|
Ok, why do you have to pay? You simply Copy the address and paste it into a Block explorer and viola! Total Received 0 BTC How long have you worked on this concept, because it is a bit flawed. You should find a way to scramble the incoming address to hide the original source or have a new address for every new visitor to your site and then have a single address where all the donations are collected. Once a person donates, the final bitcoins collected are displayed to the donator. ^smile^
Good idea for fun, but put a little bit more work into this.
If you refresh the page, you will get a new address. It gives each person a new address, so you actually can't know unless you happen to know all of the addresses that have been given out. |
|
|
|
|
Your question is incredibly vague.
In what way were the Bitcoin "sent back" to you? Did you receive a transaction? Or did your balance just not update after you sent the transaction? Or did your balance update after you sent and then it added the coins that were sent back to your balance?
|
|
|
|
rpcuser=<username> rpcpassword=<password> Don't use rpcuser and rpcpassword, they are deprecated. Instead use rpcauth. A script for generating that is available here: https://github.com/bitcoin/bitcoin/tree/master/share/rpcuseryes but what does the asterisk on the ip mean?
It means allow any IP address on the range 192.168.1.0 to 192.168.1.255. Of course you should be using your actual IP address that will be making the connection, not your local IP address if you are not on the same local network. Since you are using a VPS, double check that the VPS provider does not have a firewall blocking the ports that you want. Sometimes they will have an external firewall which you must configure from your account and not on the VPS itself. |
|
|
|
It appears in the transactions list in Armory (with 0 in the far left column — for number of confirmations?), but does not appear in the blockchain.
If the transaction is unconfirmed of course it won't appear in the blockchain. Do you mean you can't find the transaction on blockchain.info (which, by the way, is NOT the blockchain)? |
|
|
|
|
Please post your log files.
|
|
|
|
Right, I've restored the wallet from the paper backup. Everything is synced and loaded. Transaction history has been scanned etc I cannot send any BTC. I keep getting a tx timeout error or Armory just crashes. Armory log: https://pastebin.com/Dy91xLnGdblog: https://pastebin.com/CWM1R6JHI've tried with a few times with higher fees but just cannot send. What is up with this? This is a known issue that has been "fixed" (not really, just hacked to not fail) in the latest 0.96.1 testing build. You should upgrade to that, available here: https://github.com/goatpig/BitcoinArmory/releases/tag/v0.96.0.3-testingDon't keep trying to spend after the first error. You'll end up making a bunch of double spends and that is bad. |
|
|
|
|
If the RPC succeeds then the transaction was broadcast successfully. You should be able to look it up on any block explorer. Do you see the transaction in your transactions list?
|
|
|
|
So, let me clarify, a node = blockchain, right?
No. A node is a computer that is connected to other computers and sends and receives data to those other computers. All nodes on the Bitcoin network use the same blockchain. And, blockchain = where all the balances of the users lives and all the transactions
Yes. So what i understand is, that a node can only be connected to a node, not to many? If i had 4 nodes, A, B, C, D, it would look like this:
A->B->C->D , or can a node be connected to more nodes? like this:
A->B
A->D
B->D
B->C
A node can connect to many nodes simultaneously. |
|
|
|
i am guessing no, but worth the ask, is this new update going to be compatible with the Segwit2x that's suppose to go live August 1'st? and BIP 148?
No. The Bitcoin Core developers do not support Segwit2x or any of the other hard fork proposals. There also is not consensus about BIP 148 so that is not supported either. |
|
|
|
Thank you, I understand that it doesn't look like a properly formatted key but if you import it into a software that accepts it, you will see that this WIF produces a bitcoin address that has a number of confirmed outbound transactions. So as far as I understand this key was successfully used to sign outbound transactions. Doesn't it make it a fully functional key across bitcoin network?
The key that has a value of 0x1 is itself a completely valid private key. However when made into a WIF private key, the only way to make a valid WIF key is to zero-pad it so that it has the same size as a 256 bit integer. So the data that gets Base58Check encoded must be 0x00000000000000000000000000000001 and that must be the data that comes out from decoding it. Just because something is a valid Base58Check encoded value does not make it a WIF private key (e.g. addresses also use Base58Check encoding). There is a difference; WIF is a specific type of Base58Check encoding (must begin with a 5, K, or L and be 51 or 52 characters long). |
|
|
|
Ohh, thank you. So basically:
when a new node connects, it connects to a "master list server" (or many), requesting nodes, this will return a node list with many nodes? or one?
It is a list with a couple of nodes. IIRC it's something like 5 or 6 nodes. Then the transaction will broadcast to another node, and than this another node broadcast this transaction to other, and so on, right?
Yes. And how many times a transaction go through nodes?
It goes through once. Each node will only broadcast the transaction once. This means that if a new node join the network after a transaction has been broadcast to all nodes, they won't receive the transaction until it is confirmed. And who updates this "master list server", everytime a new node connects there the "master server list" saves it as a new node?
I'm not sure how often the DNS seeders are updated, but IIRC they use a bot (each server has its own bot) to connect to nodes, request some IP addresses from them, and connect to those and repeat. This way they can tell who is still online and build up a large list of potential node IP addresses. |
|
|
|
Hey Thanks,
but to whom get i connected?
To a central node? or to other peopple?
And for example, at the beggining of using bitcoins, when i download a wallet it should connect somewhere to get a list of nodes, right? a masternode or central server?
If not how do i get
"all of the nodes that it is connected to" ?
Peer discovery (the process of finding nodes to connect to) is a fairly complicated process. When a new node starts up, it first connects to multiple DNS servers. These servers (there are 6 of them all run by different people) will provide the node with a couple of IP addresses for it to try to connect to. Those DNS servers are not necessarily nodes and do not provide a definitive list of all nodes on the network. They just operate crawlers which gather the IP addresses for many Bitcoin nodes. If the DNS servers are unavailable, there is also a hard coded list of ~1000 nodes which the node software will go through to find connections. That list of nodes is gathered from the DNS servers by going through the list of all nodes that the server knows about and picking those nodes with the highest uptime. Once a node has a connection to another node, it will begin building a database of available nodes. This is done by asking each node that it is connected to for a list of IP addresses that those nodes know about. That list is then added to a local database. From then on, every time the node starts, it will first go through its database of nodes trying to find some to connect to. Lastly, a node may not necessarily use the IP addresses sent by the DNS seeders except for maybe 1 or 2 connections. This is because it will receive the IP addresses of other nodes from the first couple of connections and can then use that information to establish connections to other nodes which the DNS seeder did not give out. |
|
|
|
|
When a transaction is broadcast, your node sends the transaction to all of the nodes that it is connected to. Then those nodes will send the transaction to all of the nodes that they are connected to. And so on and so forth until every node has heard the transaction. Your node is not actually broadcasting the transaction to everyone.
|
|
|
|
|
It seems that ArmoryDB is unable to get past block 470924. Is Bitcoin Core running and is it fully synced?
There seems to be a problem with getting transaction data from ArmoryDB, but I can't really tell what is wrong. The most obvious issue right now seems to be that the db is constantly rescanning block 470924 and can't seem to get past it.
|
|
|
|
|
Do your private keys begin with a '5', 'K', or 'L'?
If it begins with a '5', is the private key 51 characters long?
If it begins with a 'K' or 'L', is the private key 52 character long?
If none of the above, then you don't have a valid private key.
|
|
|
|
1. On the page above, if I set a private key as a number, say 1, then the WIF looks like 26k9aD1PF, which is a valid WIF and accepted, say, by Electrum wallet. However, bitcoind says "Invalid private key format".
That is not a valid WIF key. The key is too short. It seems that the website is not making the number you enter a 256bit integer before making it a byte array to be hashed and converted to WIF. The number must be a 256 bit integer, so you will have to 0 pad the number you enter for the page to actually generate a valid WIF key. tl;dr the site is wrong. What kind of WIFs does the current version of bitcoind support?
There is only one kind of WIF key. What you thought was valid was in fact invalid. It was simply a number in Base58Check encoding. But that does not make it a private key in WIF. 2. I noticed that in the wallet dump all WIFs generated by bitcoind start with K or L, so as far as I understand they are for production of compressed public keys. How do I generate this kind of WIFs from a private key as a number? In this case, what's the difference from steps described on http://gobittest.appspot.com/PrivateKey?Compressed keys have an extra 0x01 byte on the end of the payload that is hashed for the checksum. |
|
|
|
Ok, this looks fun. A couple quick questions. Once the user is sitting there with the unsigned TX, does the software help them take that the rest of the way and broadcast it or is that the end of the line and the user has to figure the rest?
It will broadcast it for the user. Is the fee the only configurable part, along with the amount and addresses or can a user play with this and fiddle with various smart contract scripting and such.
Only the fee is configurable via the GUI, but if you know what you are doing, you can mess with the raw transaction itself before it is broadcast. The broadcaster doesn't actually check if the transaction was what it was even modifying. It will just broadcast whatever you give it. |
|
|
|
|
Show Posts
