Bitcoin Forum
January 23, 2019, 04:07:49 AM *
News: Latest Bitcoin Core release: 0.17.1 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 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 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 ... 550 »
1101  Bitcoin / Development & Technical Discussion / Re: Where/how is on disk/network block size determined and stored? on: November 03, 2017, 09:38:13 PM
1. Where is the size of the actual block stored in the message? Do you just send a TCP message ahead of the block that says "hey, the next block is 875,489 bytes long!" or is it encoded somewhere in to the block structure itself (apparently it isn't in the block header)?
Bitcoin has several P2P network messages, one of which is the Block message. Each P2P message (not just the block message) has a message header which contains information about the rest of the message, including the size in bytes of the message. You can read about the message header here: https://bitcoin.org/en/developer-reference#message-headers

2. Similarly, on disk, where is the record of how big each block is (so the filesystem knows how much data to read)? Is that in the chain state database, or it is stored in the BLK*.dat files themselves? Or somewhere else?
The blocks are stored disk as they are received over the network (without the P2P message header) with an additional compact size unsigned integer before the block indicating its length.
1102  Bitcoin / Development & Technical Discussion / Re: Difference between SegWit addresses on: November 03, 2017, 02:36:46 PM
Is the sensitivity of case really important? I'm sure most people use their mouse to copy and paste the address.

In situations where people don't copy and paste, it helps to reduce the chance of errors.
Not only that, but the bech32 addresses use BCH codes (well BCH-like codes) which are an error correcting code. Bech32 addresses can detect up to 4 errors when entering the address and tell you where those errors are. They can also correct up to 2 errors (IIRC) but no wallet will actually do error correction for you because that is a good way to accidentally send money elsewhere.
1103  Bitcoin / Bitcoin Technical Support / Re: How can I send a message with a transaction? on: November 02, 2017, 06:04:08 PM
The message that Satoshi included in the Genesis block is actually part of the Coinbase transaction of that block. Specifically, in the input of any Coinbase transaction, you can include whatever data that you want. Satoshi chose to put a string there. So if you want to do the same thing, then you must be a miner and set whatever you want in that part of the coinbase transaction of your blocks.

There are other ways to embed data in transactions. You can use an OP_RETURN output which allows you to make a provably unspendable output that has arbitrary data in it.
1104  Bitcoin / Development & Technical Discussion / Re: Payment No. 1: A Closer Look at the Very First Bitcoin Transfer on: November 02, 2017, 03:09:23 PM
1Q2TWHE3GMdB6BZKafqwxXtWAWgFt5Jvm3 is the address that Hal Finney said was his according to OP. This had been silent since 2009 till it moved 0.034337 BTC to 1Nt1SwDjXmbF61XDq7vjA51hbUuzKU97Lq in JUNE THIS YEAR!!

This is the only address funded by original Satoshi Bitcoins that showed activity recently!!
WHAT DOES THIS MEAN? IS IT A BIG DEAL OR JUST NORMAL SATOSHI NAKAMOTO GANG..?? Cheesy
It means nothing. Hal left his Bitcoin to his family so they have control of his private keys. It is likely that they are only now figuring out what to do with his Bitcoin and how to move it around.
1105  Bitcoin / Bitcoin Technical Support / MOVED: New to bitcoin on: November 02, 2017, 02:52:40 PM
This topic has been moved to Trashcan.

Zero value intro post
1106  Bitcoin / Bitcoin Technical Support / Re: FORGOT PRIVATE KEY on: November 02, 2017, 02:03:24 AM
If you do not have access to any file which contains it or you do not remember any passwords that would allow you to access the private key, you cannot recover it and any Bitcoin associated with that key is lost.
1107  Bitcoin / Development & Technical Discussion / Re: Have Transaction Malleability been solved with segwit? on: November 02, 2017, 12:42:59 AM
Hello, I was reading about transaction malleability and wondering if segwit solved it?
As far as my understanding of transactions in block goes, segwit's main purpose was to move signature to the different place in transaction hierarchy (from inputs section to whole new section). That effectively means that transaction ID represented by hash of transaction inputs+outputs+signature can't be tampered with anymore.
Segwit defines new output types which have their signatures moved to a new field called the witness. The witness is not part of the txid so the txid only consists of data that cannot be changed. Only transactions which spend from the segwit output types are non-malleable.
1108  Bitcoin / Bitcoin Technical Support / Re: Bitcoind starts at reboot but RPC calls wont work on: November 01, 2017, 06:38:42 PM
Add -daemon to the crontab command or add daemon=1 to your bitcoin.conf file.
1109  Bitcoin / Bitcoin Technical Support / Re: 2 inputs - 2 outputs - different size? on: November 01, 2017, 03:28:02 PM
And now check this one:
https://blockexplorer.com/tx/f83eac6755eb530ae7640684e887f8083da331c0c465cc16d3f10a179eb21594
Here, blockexplorer states 663 bytes as the transaction size which is nearly double than the 370 bytes.

What is wrong with my assumption?
There are multiple types of inputs and outputs, Your formula only works for one specific type of output and its spend in an input. The above transaction spends from a different type of output and creates a different type of output so your formula does not hold.
1110  Bitcoin / Development & Technical Discussion / Re: Bitcoin Scalability? on: November 01, 2017, 03:19:50 PM
What is the advantage of having smaller blocks?
Smaller blocks can propagate with less latency and bandwidth and also require less resources to validate. Smaller blocks allow for more people to run full nodes as the network bandwidth requirements are lower. Larger blocks will likely lead to fewer full nodes and an increased orphan rate.

All of the data gets converted to a merkle root at a later date anyway so there shouldn't really be a size problem should there?
No, that does not happen. The section about that in the whitepaper only refers to on disk storage for which we have a much more efficient method: pruning. The network and computational requirements still exist as full blocks still need to be uploaded and downloaded and then verified.

Besides, I thought that the block size is undetermined anyway - It's up to the miners to choose how many transactions they want to put in each block.
There is a maximum block size which full nodes enforce.

Is there something in the current protocol that is stopping miners from including, let's say, 100,000 transactions in each block?
The maximum block size which has been redefined by segwit to be block weight.
1111  Bitcoin / Development & Technical Discussion / Re: How is it possible to measure the amount of nodes that are just "listening" ? on: November 01, 2017, 03:15:52 PM
I take it you're arguing that SPV wallets don't "verify transactions" but they verify that the transaction is included in a block?
Yes. SPV wallets are not actually verifying the transaction itself as they can't. They can only check whether it is in a block, and even then, they have to trust that the data they are getting from the node is correct as they can't verify whether a block is valid without having verified the full blockchain.
1112  Bitcoin / Bitcoin Technical Support / Re: I found a better way of estimating on-chain BTC volume, on: October 31, 2017, 10:48:40 PM
Instead of requesting each transaction individually, request the block with verbosity level 2 (just another parameter with the value 2). This will also include the JSON data for each transaction instead of just the txids.
1113  Bitcoin / Development & Technical Discussion / Re: How is it possible to measure the amount of nodes that are just "listening" ? on: October 31, 2017, 06:19:27 PM
Listening and non-listening nodes do exactly the same thing. They still send and receive blocks and transactions from their peers and will relay blocks and transactions to their peers.
Do non-listening nodes change their 8 peers more often than listening nodes?
Connections, both inbound and outbound, are rarely closed unless one peer goes offline. So listening and non-listening nodes will change their peers at about the same frequency. Outbound connections in general might change more frequently as we have stricter criteria for who we connect to and when to disconnect from them than we do with inbound peers.
1114  Bitcoin / Development & Technical Discussion / Re: What to do for Nov 2017 hard fork. on: October 31, 2017, 06:17:17 PM
then what do you suggest mate? if someone has funds on electrum?
Are you blind? Is my signature visible?
That commit was reverted: https://github.com/btc1/bitcoin/commit/98c0af58c29efbecba25818adb5531fa8c3d0506 so that is no longer a viable method.
1115  Bitcoin / Development & Technical Discussion / MOVED: Difficulty and mining relation on: October 31, 2017, 03:39:34 PM
This topic has been moved to Trashcan.

Duplicate thread
1116  Bitcoin / Development & Technical Discussion / Re: How is it possible to measure the amount of nodes that are just "listening" ? on: October 31, 2017, 03:38:26 PM
Come on we're playing semantics. Yes, obviously a SPV wallet doesn't fully verify like a full node does, but it does simply verify transactions which is the point. It has limited trust to a third party and since the information it receives from a third party is cross verified with others and
The point is that SPV wallets can't and don't "simply verify transactions". There is no verification that can be done without having the transactions that a transaction spends from.

it is deep in the blockchain, there's a fair assumption of truth in it.
That's also not true. A transaction is not necessarily deep in the blockchain. SPV wallets allow you to receive unconfirmed transactions and sometimes spend from them. You can also spend from transactions with one confirmation; those are definitely not "deep in the blockchain"

The point is that every person isn't going to run a full node, and you want all users to have a decentralised self verifying experience. SPV nodes on mobile are the best answer to this.
Yes, I agree that not everyone is going to run a full node, but current SPV wallets are not a decentralized self verifying experience at all.
1117  Bitcoin / Development & Technical Discussion / Re: Generate block by the help of cgminer and getblocktemplate on: October 31, 2017, 03:34:28 PM
I changed the difficulty in the GetDifficulty() function in the following file.
~/bitcoin/src/rpc/blockchain.cpp.

I set a huge big number such as 99999999999999999.
That is not at all how difficulty works and not where it is changed. What you changed was the output of an RPC command, not any actual internal behavior.

First of all, Bitcoin does not actually use the difficulty number in mining. It uses a 256 bit integer called the target and a block's hash must be less than that target value. That target value is in turn used to calculate the difficulty value for us humans to understand, but the difficulty value itself is not used in Bitcoin anywhere.

I simply want to know the difference between block generation speed in two cases; when difficulty is set to 1 and when is changed to 1.0e+15.
Do change the difficulty, you will need to change this value to false: https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp#L281 and modify these two functions: https://github.com/bitcoin/bitcoin/blob/master/src/pow.cpp#L49 and https://github.com/bitcoin/bitcoin/blob/master/src/pow.cpp#L13 to give you a target that matches the difficulty that you want to have.
1118  Bitcoin / Development & Technical Discussion / Re: Reusing receive address doesn't reduce tx size on spending, right? on: October 31, 2017, 04:25:59 AM
Could you have all your coins sent to a single address, and then make a second transaction of all those coins once again to a single address? Would that reduce the UTXO set?
Yes, you could do that. That would reduce the UTXO set. You wouldn't need to have all your coins sent to the same address in the first place, although if they were, there is then no harm to your privacy.
1119  Bitcoin / Electrum / Re: Electrum wallet shows "replacable" after transaction on: October 30, 2017, 07:24:34 PM
Thank you for the answer.
Does that mean that the transaction will be executed later or do I have to raise the fee? I could do that. The Elektrum wallet allows to that.
What is the best thing to do? But not do the same transaction again, right?
The transaction will confirm eventually, you do not need to do anything. If you think the transaction is taking too long to confirm, you can increase the fee.
1120  Bitcoin / Development & Technical Discussion / Re: Reusing receive address doesn't reduce tx size on spending, right? on: October 30, 2017, 07:24:18 PM
Is there a standard way to generate P2PK receive addresses?
No.

Aren't 1-prefix addresses just for P2PKH?
Yes.

BTW, a few posts were deleted from this thread, which happens a lot on the forum. How come?
A lot of them are spam or low value. I will delete posts from people who clearly do not read the thread and just post the same thing that someone else posted earlier in the thread.
Pages: « 1 ... 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 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 ... 550 »
Bitcointalk.org 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!