|
@op
What would you call easily auditable and platform independent?
Technically, you could create a transaction with a pen, pencil and a calculator.
|
|
|
|
|
If the number of leaves is a power of 2, the total number of nodes is 2n - 1.
If it's not, there are extra nodes introduced to fill in the holes. Let m be the number of these extra nodes. The total number of nodes become 2n -1+m.
When n is written in binary form, a division by two is equivalent to a bit shift to the right. As long as the last digit is a 0, the number is even.
Therefore all the trailing zeros are levels that are even and don't introduce new nodes.
When we reach a 1, a extra node is added. It is carried to the next level. Ex: 101. Without extra nodes, we have 1 at the root. 10 on the second level and 101 on the third. but the extra node made the 3rd level 110. And the second level is now 11. It's odd again, so an extra node is once again added. And it becomes 100.
We can see that the process of adding nodes continues for every 0 that appears after the first 1. Because the carry made the number odd.
When we reach a 1. The carry turns that into a 0 and carry a 1 further. Therefore the 1 has no effect of the number of extra nodes.
In conclusion, the number of extra nodes is 1 + the number of zeros that are to the left of the first 1 that is not the most significant bit.
The final result is 2n + number of non trailing zeros.
Credits goes to Meni for the formula.
|
|
|
|
Some other queries: Top 10 richest addresses: select address, balance / 1e8 from balances order by balance desc limit 1,10;
1i7cZdoE9NcHSdAL5eGjmTJbBVqeQDwgw 144341.53393243
13Df4x5nQo7boLWHxQCbJzobN5gUNT65Hh 134033.21518705
1FeexV6bAHb8ybZjqQMjJrcCrHGW9sb6uF 79957.05831838
1HQ3Go3ggs8pFnXuHVHRytPCq5fGG8Hbhx 69471.09995224
16ZbpCEyVVdqu8VycWR8thUL2Rd9JnjzHt 61693.55853673
1PB4xXUFyy4kSNqroCBVaQuCuw9VcN3be4 61544.25018469
1PnMfRF2enSZnR6JSexxBHuQnxG8Vo5FVK 61534.65308581
18f1yugoAJuXcHAbsuRVLQC9TezJ6iVRLp 61517.02586555
1DiHDQMPFu4p84rkLn6Majj2LCZZZRQUaa 61442.99572266
1AhTjUMztCihiTyA4K6E3QEpobjWLwKhkR 61387.07600804
select count(*) from balances;
3460367
The median is only 1 mbtc select address, balance / 1e8 from balances order by balance asc limit 1730183,1;
1H6c1fDEzJBhvViHhtrW5L9YTuSfRNp44w 0.001
Total balance select sum(balance) / 1e8 from balances;
13316310.28675084
The top 18 (0.0005 %) addresses own 10% of the total select sum(balance) / 1e8 from (select balance from balances order by balance desc limit 18) as T;
1345428.14052543
The top 3000 (0.09%) own more than half select sum(balance) / 1e8 from (select balance from balances order by balance desc limit 3000) as T;
6820871.23187743
|
|
|
|
I found different results. addr count total balance
1BiT 11784 990.72856
1Btc 1015 2415.5241782
1MUo 614 169.74258679
1tip 588 9.21681564
1CaR 557 479.44438884
1Pay 511 502.95050021
1MaR 506 242.68727996
1AGa 496 835.41160235
1AgZ 463 429.46682356
1AGB 452 470.97131551
1Agw 443 515.40205199
1CHA 428 1142.89394438
1AGY 427 1293.95860474
1BaN 409 650.5419544
1CaN 402 435.30669108
1CAs 391 2208.6754669
1AgX 390 459.49381862
1BrA 367 229.65373024
...
For a total of 3.4 mil addresses |
|
|
|
|
You don't need to parse the blockchain. You can use the RPC JSON API to bitcoin core, electrum, blockchain.info, etc.
"getblock"
|
|
|
|
Has your full node re-implementation been reviewed? The Core developers usually discourage people from re-implementing the bitcoin protocol as the people fix intentional quirks.
Really? I'm surprised by this attitude in an open source project. |
|
|
|
Besides the official client, what options do we have? I know of - BitcoinJ - btcd - gocoin https://en.bitcoin.it/wiki/ClientsIs there a client that implements BIP 37, ultra pruning and/or partial blockchain? Thanks, --h |
|
|
|
Ok. Perhaps I discribed it wrong. But not to see if it is a valid public key. More if it is a public key. Thing like that it is >= 25 && <= 34, begins with 1 or 3(?). And things like that.
But perhaps it's enough to see if it is a valid base58check as you said. Didn't know of that. So Perhaps it's what Im searching for. Thanks
You can convert back to Hex. Then verify the checksum and the version byte. The later is what differentiates a bitcoin main address from a testnet address or a altcoin address. Perhaps you are mixed up, a Bitcoin address and a public key are two different things.
A bitcoin address looks like this:
1HZwkjkeaoZfTSaJxDw6aKkxp45agDiEzN
A public key looks like this:
04a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd5b8dec5235a0f a8722476c7709c02559e3aa73aa03918ba2d492eea75abea235
If you want to check if a public key is valid, you can also check the length and check that it is hex. There is no checksum on ecdsa pubkeys.
There are some checks you can do on a public key. There are two types of pub keys in bitcoin: compressed or uncompressed. They are 33 and 65 byte long respectively. If it begins with 04, it's uncompressed. If it's 02 or 03, it is compressed. So you can check the first byte. If it's uncompressed, the next 32 + 32 bytes is the X and Y coordinates of a point on the Y^2 = X^3 + 7 curve. You can check that too Note that it must be done modulo N = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141 If it's compressed, only the X coordinate is given. It must be lower than N This can be done by your EC crypto library when you decode the pubkey. |
|
|
|
It's not just the longest chain that wins, it's the chain with the most amount of work behind it.
@9kv Like @impulse said, if you mine with a lower hashrate, either you won't find blocks as fast as the rest of the network or you have to lower the difficulty to compensate. In either case, you will be behind when you merge back to the main chain. Every block has a 'nonce' and a 'bits' field. The nonce lets the miner tweak the hash, the bits translates to the difficulty - how much tolerance you accepted on the hash. The network verifies both. If your nonce gives a hash too high for your bits then your block is invalid. If your bits is too low, you are not competitive and your block is rejected. Without this, the system is totally broken. Hypothetically if the bits were not part of the calculation: You run bitcoin core in regtest mode. It creates a private blockchain starting with the same genesis block. Issue a 'set generate true 1000000' to produce 1 million blocks at the lowest difficulty with all rewards going to your wallet. And then broadcast it to the network. Your chain wins and the entire blockchain is wiped out. |
|
|
|
|
Well, a hash is 20 byte long and the public key is 'nearly' 32 byte long. So essentially, there are thousands of public keys for any address. But of course, you can't check whether someone knows the matching private key.
|
|
|
|
|
Are you looking for an exact number? If an approximation is ok, it's simply half. We can prove it like this:
A merkle tree is a binary tree which is essentially a direct elimination tournament. When two hashes are combined, one hash is produced.
So if you start with N leaves and keep on combining nodes, every time you reduce the number by 1. To get to a single node, therefore we have
to do N-1 combinations and the total of nodes is then roughly 2N. This is true, regardless where you combine nodes in the tree.
However, the merke tree also adds nodes when there is an odd number of nodes in a given level. You have at most log_2(N) extra nodes added, i.e.
one per level of your tree. So the number is between 2N and 2N + log2(N). As N grows, the term is log is negligeable.
I'll try to find an exact formula.
|
|
|
|
That inflation is too high. There is no need to discuss it. That's a fact.
The high inflation doesn't serve its purpose, it just scares investors away.
Sorry, but the fact is that you don't know what inflation is. However, you are free to invest in anything you want. |
|
|
|
|
Let's assume that we stick with the plan: no fractional reserve and no extra coins.
What we see is not inflation but distribution like someone said earlier.
We know the final number so this is as if some hidden entity is holding 21 million coins and is offering them for sale little by little. It is the same as if bitcoin was a private company and its owner starts giving shares.
The big difference with inflation is that the latter is unknown.
Whereas with bitcoin, you can factor the growth in your valuation. I take what I think the final market cap should be and you divide by the final number of coins.
obviously, I will be wrong but inflation is not the reason. in short, the current number of coins is not very useful
|
|
|
|
The largest advantage is it can lead to lite clients which don't need full blocks and instead can request block headers and merkle branch from other nodes. This isn't implemented yet and I believe one of the developers indicated it may require a seperate protocol.
The use of merkle tree can also allow blockchain pruning by removing older transactions once a newer transaction for a particular address is deep enough in the block chain. With a single hash for all transactions this wouldn't be possible not without some mechanism to re-sign the pruned block and that would require some sort of alternate proof-of-work to ensure decentralized consensus.
More generally speaking using a merkle tree allows more granularity in transaction validation. You can validate an entire block, a group of transactions, or just a single transaction. Using a merkle tree allows options to deal w/ future issues that the network may need to deal with.
If I understood correctly what you mean is that the entire block will be removed from the blockchain. Wouldn't that compromise the whole blockchain since each block includes the hash of the previous block, and therefore if one is removed then its reference in the next block will be not verifiable (as the block was removed). Not the entire block. There are two hashes. The block hash that only covers the header and the merkle root that covers the transactions. The block hash is simply a hash over the bytes of header. The merkle root hash is more sophisticated. All the transactions are put in a binary tree. Then the leaves (= the transactions) are hashed. Afterwards, the parents are hashes of the concatenation of the 2 children. And so on so forth until the root. With a merkle tree, one can replace part of the data by a hash while still proving that the remaining data hasn't been compromised. As the block chain gets older, old transactions will become irrelevant because the money that were at these addresses is spent. Today, a full node carries the entire block chain. A smart client could detect that these transactions are useless and remove them from their block. It will leave a 'hole'. When two holes are next to each other, they can be combined into a bigger hole. Finally, the hope is that the block chain becomes much smaller. |
|
|
|
|
The miner adds the first transaction to his solved block that indicates where he wants his fees and reward distributed.
Since this transaction has no input, the input script is ignored. He can write whatever he wants there.
|
|
|
|
By such logic, nobody really owns their phones either, they were assembled in China, not by us
Or even own any cash money since it belongs to the government. It's illegal to burn money in many jurisdictions. To the people who boldly advise the OP to stick it to the man, how many of you would keep that stance if they are the one facing the consequences? I would seek professional legal advice. |
|
|
|
Thanks ffe, but I'm looking for something that does not require an external server. I've managed to prototype this using Bitcoinj, if anyone knows of a better/simpler solution, I'm all ears. Again, this must receive/parse transaction data from the Bitcoin network, not talk to a server.
Coincidentally, I just wrote an app for a very similar purpose. The only difference is that it takes an Electrum public master key instead of a single address but it's much smaller than bitcoinj or anything else so you can easily modify the code for your needs. https://github.com/hhanh00/spvwallet |
|
|
|
|
I did the following:
1. Send a version msg with relay = 0 (don't get inv messages until filterload)
2. Response to version from node with verack
3. Wait for verack from node
Now I'm ready to talk to the server
1. Send an empty filterload
--> I start getting some Inv messages back. I thought I shouldn't get any but maybe it's for DoS protection?
2. Send a filteradd message passing a pubkey where I've got a few mbtc
045e2a21f9e0de43b9ff9c898efcaffd45c78a3b12161fe834266fc9f34c186e6b7de09942beb8e d7039a61d146330ca286f2fb86fec6a181f96d9c59d13695e6d
Still getting inv messages...
Basically, how should I get the actual transactions so that I can calculate the balance?
Thanks,
--h
|
|
|
|
It's not a future contract but a swap. The margin calls do not work the same way. So this swap is an agreement to sell bitcoin at an agreed rate in the future, right? Does it mean merchants who accepts bitcoin do not need to sell the bitcoin they received on the exchange immediately?
Someone asks if it's like a future and then a bunch of people reply "yes". Now this thread assumes it's a future. No offense but this is how misinformation is spread. |
|
|
|
|
Show Posts
