One thing to notice is that both blocks contain exactly 256 transactions I think 477115 has one tx less. |
|
|
|
Not sure if it is on any interest for anyone here, but I remember once, when a BU node mined an invalid block, people were shitting themselves all over the internet. Well, not sure that kind of software 1hash pool uses, but they have just mined their second invalid block. It's easy to find them these days, because nodes relay them before fully verifying. The first invalid block they mined was #474294, with hash 00000000000000000182acdf5657c93a0769dc6f9004047496b2e15efc6a4232 The second one, just a few hours ago #477115, with hash 0000000000000000013ee4a86822d37a061732e04ee5f41fb77168f193363d1b You can download both of them from here: http://gocoin.pl/1hash/474294-00000000000000000182acdf5657c93a0769dc6f9004047496b2e15efc6a4232.binhttp://gocoin.pl/1hash/477115-0000000000000000013ee4a86822d37a061732e04ee5f41fb77168f193363d1b.binI haven't checked yet why exactly they are invalid, but I think the order of the transactions inside the block is screwed up. They use an input from a tx that is only created later in the block. I'm thinking they must be using come customised mining software which (sometimes) assembles the block incorrectly. So I thought I'd let them know, before they mine the third broken block, still without anyone noticing  |
|
|
|
|
Thanks.
You need at least 8 GB of RAM.
I'm unaware of any raspberry pi having that much.
As soon as you have a Linux board with that much ram, there should be no problem to run gocoin there.
It is possible, but I'm not sure if anything like this (cheap arm cpu board with 8+GB of RAM) is available on the market.
As for the storage space requirement, you can purge blocks database regularly, in which case 16 GB of storage should be enough.
If you want to keep the entire block chain though, you need about 120 GB, as of today.
|
|
|
|
install gocoin client, wait for it to sync and execute command "richest" on the text UI the output looks like this: > richest
...
12558300.98255215 BTC in 41811145 unspent recs from 15897180 P2KH addresses
2082477.58073845 BTC in 9340715 unspent recs from 2211460 P2SH addresses
Addrs with at least 1000 BTC: 1758
1 1JCe8z4jJVNXSjohjM4i9Hh813dLCNx2Sy 124178.00646844 BTC in 38 inputs
2 3D2oetdNuZUqQHPJmcMDDHYoqkyNVsFk9r 109132.22274888 BTC in 852 inputs
3 3Nxwenay9Z8Lc9JBiywExpnEFiLp6Afp8v 107843.83930984 BTC in 80 inputs
4 1FeexV6bAHb8ybZjqQMjJrcCrHGW9sb6uF 79957.16158573 BTC in 102 inputs
5 1HQ3Go3ggs8pFnXuHVHRytPCq5fGG8Hbhx 69370.10708424 BTC in 72 inputs
6 16ZbpCEyVVdqu8VycWR8thUL2Rd9JnjzHt 66650.59647895 BTC in 173 inputs
7 1KiVwxEuGBYavyKrxkLncJt2pQ5YUUQX7f 66583.22399047 BTC in 123 inputs
8 1PnMfRF2enSZnR6JSexxBHuQnxG8Vo5FVK 66452.06632292 BTC in 117 inputs
9 1AhTjUMztCihiTyA4K6E3QEpobjWLwKhkR 66378.80968619 BTC in 184 inputs
10 1DiHDQMPFu4p84rkLn6Majj2LCZZZRQUaa 66235.82433198 BTC in 129 inputs
11 1EBHA1ckUWzNKN7BMfDwGTx6GKEbADUozX 66233.75696244 BTC in 129 inputs
12 14e7XAZbepQp9MXXzjNG3fNLoAUpaBAXHW 66205.47376047 BTC in 133 inputs
13 18f1yugoAJuXcHAbsuRVLQC9TezJ6iVRLp 66163.44526030 BTC in 126 inputs
14 18rnfoQgGo1HqvVQaAN4QnxjYE7Sez9eca 59000.00134500 BTC in 137 inputs
15 1LdRcdxfbSnmCYYNdeYpUnztiYzVfBEQeC 53880.05742758 BTC in 22 inputs
Ready in 4.709s
>
it shows top 15. if you need more, e.g. 100 - just do "richest 100" instead. |
|
|
|
How can I unban a peer?
You can start the client with -unban to unban all peers. |
|
|
|
|
I can refer you to articles saying that using bitcoins in general is a bad idea because you don't know what you're doing and therefore you can easily loose your coins.
Obviously, if you don't know what you're doing you can easily loose your coins - it doesn't take a genius to figure that out.
If you do know what are you doing, at the other hand, and if you know what you want, brain wallet might be just the best way to go for you.
Which my and my friends' brain wallets have proven true for years.
So cut off the crap as I'm quite tired already listening to this dogmatic bullshit that you dare to call 'research'.
|
|
|
|
As you all are most likely aware of, it is possible to import any SHA256 hash as a bitcoin wallet private key. You can generate SHA256 hashes on this website: http://passwordsgenerator.net/sha256-hash-generator/Is it possible to check on an offline computer which bitcoin address it corresponds to? I'm thinking about creating a brain wallet on an offline machine to store bitcoin on. Thank you for any help see my gocoin wallet. http://gocoin.pl/gocoin_manual_wallet.htmlhttp://gocoin.pl/gocoin_manual_spending.htmlin your case, you'd have to convert the SHA256 values into the private key base58 encoded strings and put them into .others file. but you can also just feed the wallet with a memorable seed password and it will create 250 deposit addresses for you. just remember that my algo of calculating the hash (private key) is different. then you use the same software to spend your coins (sign transactions) at an offline pc. for that you will also need a tool called "balio" (assuming you don't want to run gocoin node). |
|
|
|
anyway, do you have any suggestions about this OP_CSV problem? if the push does not matter in OP_CSV as you said it only saves a byte per input. I already have set the version to 2, then what else, did I miss something?
I just told you what was the problem. the push does matter! why don't you just try it? change tx version to 2 and {0x01,0x0a} to 0x5a inside the spending script, and it will work. trust me. obviously, you won't be able to spend the existing output through the else condition. because it contains "illegal" pushes. you need to make another P2SH address, for the script with 5a (instead of 010a) |
|
|
|
|
OK.
So I can't explain what was happening.
It stopped happening now, again.
But there was something odd about it.
I'm talking about maybe tens of nodes max doing this.
I have over 7000 nodes in my peers database - only ones that I've heard about during the last 2 hours.
What are the odds that when I start the node and it needs to choose 8 addresses to connect to, it gets 2, 3 or 4 of the ones that send the wrong IP?
And that's exactly what I was seeing when these nodes were alive - repeatedly, each time when I was starting my node.
Their IPs had to be advertised (via the addr messages) much more often and with some fresh timestamps.
It's the only explanation that I have.
|
|
|
|
|
They seem to be an actual nodes, but whether they implement the entire protocol, or just the version handshake is irrelevant at this stage.
They still mess up with the local IP discovery mechanism used by the recent software.
These nodes seem to be getting advantage on how often they are connected to, as their "victims" advertise their IP as own.
|
|
|
|
A few hours after I started this topic yesterday, the nodes stopped broadcasting bad IPs. And for a few hours the network was all fine. But now they are back, except that this time they introduce themselves as Bitcoin Unlimited or Classic. It's really silly and I'm dying to find out how it's going to develop... Is this caused by a brain tumor, drugs or maybe just not enough sleep? 54.201.14.113 from /BitcoinUnlimited:1.0.2(EB16; AD12)/
54.255.174.123 from /BitcoinUnlimited:1.0.2(EB16; AD12)/
54.206.13.36 from /BitcoinUnlimited:1.0.2(EB16; AD12)/
54.252.244.53 from /BitcoinUnlimited:1.0.2(EB16; AD12)/
54.67.126.145 from /Classic:1.2.5(EB6)/
52.79.224.60 from /BitcoinUnlimited:1.0.0.99(EB256; AD0)/
54.153.100.12 from /Classic:1.2.0(EB3.7)/
54.233.103.66 from /Classic:1.2.5(EB3.7)/
34.211.145.14 from /BitcoinUnlimited - https://btcpop.co:1.0.0.1(EB16; AD12)/
54.219.166.22 from /BitcoinUnlimited:1.0.1.1(EB0; AD12)/
|
|
|
|
@sonicskye, I think your tx is failing the "minimal push" check. it's some crazy stuff that (I think) is supposed to prevent tx malleability - don't ask me about it but what you have to change is the place where you push value 10 onto the stack instead of using {0x01, 0x0a}, you should use a single 0x5a (OP_10) plus, as it was said before, you need version 2 or more - then it will work. |
|
|
|
|
How does bitcoin core discover own IP, which is then reported to new peers inside the version messages?
I think these days it's just by the value reported from the connected peers - is that right?
And then, if it has a wrong IP (of some malicious node), how could it affect the chance of other nodes to connect to that malicious one?
|
|
|
|
A number of nodes ran from the amazon cloud (all representing themselves as "UASF/SegWit/BIP148/whatever") are wrongly reporting connecting node's IP, putting own in it's place. I imagine there is a purpose in doing that. Whoever does it, I just want him to know that he might suffer from some serious issues and maybe it isn't too late yet to consult a doctor. Below some example IPs. 34.203.31.60 from /Satoshi:0.14.1(UASF-SegWit-BIP148)/
34.203.31.60 from /Satoshi:0.14.0(UASF-SegWit-BIP148)/
52.60.155.242 from /Satoshi:0.14.1(BIP8; UASF-SegWit-BIP149; UASF-SegWit-BIP148)/
54.194.206.222 from /Satoshi:0.14.1/UASF-Segwit:0.3(BIP148)/
35.154.110.140 from /Satoshi:0.14.1/UASF-Segwit:0.3(BIP148)/
34.209.234.16 from /Satoshi:0.14.1/UASF-Segwit:0.3(BIP148)/
54.250.162.133 from /Satoshi:0.14.1(UASF-SegWit-BIP148)/
54.171.65.204 from /Satoshi:0.14.1/UASF-Segwit:0.3(BIP148)/
54.93.250.167 from /Satoshi:0.14.1/UASF-Segwit:0.3(BIP148)/
|
|
|
|
I have a new update, but first of all I'd like to know if anyone is actually reading this. Please let me know if you do and if you'd like to read some updates in this topic, or I won't be wasting my energy on this forum thread. The 1.9.0 release has some reorgs inside the source code and the architecture in general. It should perform even better. Since the UTXO db only gets updated on new blocks, I decided to simply the approach and just keep a snapshot of it on the disk. It's being flushed to disk after each update (new block), but at a vert low priority so it doesn't take too much system resources. Now the whole UTXO database is caried by the single UTXO.db file, which is about 2.4 GB big. When you start the new client, it should convert your old "unspent4" DB to the new format automatically. Also, if you want to bootstrap a new node, you only need this file and the block headers file (about 60MB). I can distribute the quick bootstrap files, if anyone is interested. Which brings me to the point that the recent versions of gocoin node can work with purged blocks database. If your blocks happen to be taking too much space, just close the client and execute: Or: bdb -purgeto <block_height> This will either purge all blocks or only up ot the given height. Follow the instructions on the screen as you need some extra copying/deleting, just to be safe and not delete you blocks DB by accident. Again: make sure to not have the client node running while using the bdb tool. |
|
|
|
Apart from the P2SH, there was: * BIP34 (v2 blocks) - activated at block #227931. This change was about the block number value to be included in the coinbase. * BIP66 (v3 blocks) - from block #363725. Disallowed some encoding of the signatures. * BIP65 (v4 blocks) - block #388381. Support for OP_CHECKLOCKTIMEVERIFY. * CSV (through BIP9) - active from block #419328. Support for OP_CHECKSEQUENCEVERIFY. I think that's all. Plus the ongoing segwit. Did the "OP_HASH160 <hash> OP_EQUAL" output just automatically require checking redeem scripts when it was implemented? Redeem script is pushed onto the stack as one binary blob (as the last element, after public keys and signatures). "OP_HASH160 <hash> OP_EQUAL" hashes that binary blob and compares against the required value. Then (what BIP16 activation changed) is that the last binary blob is ten taken from the stack and executed as a regular script. So basically it executes two different scripts, one after another: first the "OP_HASH160 <hash> OP_EQUAL" one, then the spending one. |
|
|
|
However this is not a very elegant solution, as it wastes precious block chain space. I'd rather go for a smaller nonce Something like: 0x04 <4 random bytes> OP_DROP <pubkey> OP_CHECKSIGVERIFY |
|
|
|
In other words: from a single private key k, how many different addresses can we get? You can get virtually unlimited number of P2SH addresses for a single private key. You just need to hash a script with some kind of nonce. For instance, it could be 1 of 2 mulitisig, where the second key is a random number. Then in this script:
{1 [pubkey1] [pubkey2] 2 OP_CHECKMULTISIG}
instead of pubkey2 I can put any string with any lenght? No. Put something that has a format of a public key; starts from 2 or 3 and is followed by 32 bytes. The 32 bytes can be anything. As long as they aren't any known public key |
|
|
|
|
Show Posts
