 Show Posts
|
|
Pages: [1] 2 3 »
|
I've been struggling to reproduce the hashing procedure used by the RPC command dumptxoutset (for the latest release 28.0). I was hoping that maybe someone could give me a hint what I am doing wrong. I am assuming that it is using the HASH_SERIALIZED type (not the mysterious MUHASH). In which case, is should be just a simple SHA256 of all the "Coin" records, ordered like in the file created by dumptxoutset. Looking at the source code, I think each record is written to the hasher like this: 32 bytes of TxID (in the same order as stored in memory)
4 bytes of VOut (little endian)
4 bytes of 2*block_heigh+coinbase (little endian)
8 bytes of Amount (little endian)
the spending script (uncompressed, variable length, as stored in memory) So all he records go one-after-another and at the end I do another SHA256 on the result. Unfortunately, this does not work, because I don't get the value from the "txoutset_hash" filed returned by dumptxoutset. I wonder whether there is some kind of script_length filed between the Amount and the script itself? |
|
|
|
|
It seems like there is some sort of attack going on - the network is advertising hundreds of thousands of non-working addresses via the addr messages.
All my nodes' peers databases are now over 700k records and seem to be still growing...
Do you see the same at your nodes?
Does bitcoin core have a limit of peers upon witch it won't accept new addresses into the database?
How to best handle that?
Apart from the extra resources consumption, it now takes much longer to connect to new peers, because there are so many non-working addresses in the db.
|
|
|
|
|
I'm starting this new topic because I'm trying to implement the taproot functionality in my code.
I hope people can help me to understand some of the taproot technicalities.
So my first question:
How does the new verify_script function use the spend_scripts of the inputs that it is spending?
When I will verify a specific input of a transaction, will I need to have amounts and spend scripts for all the inputs, or will it be enough to have just the one at a time?
|
|
|
|
|
Is it just a problem with my implementation, or is there some sort of attack going on, exploiting the Child-Pays-For-Parent sorting algorithm?
The sorting (of the existing mempool) takes far too long.
|
|
|
|
I've been observing for some time already that there are multiple nodes who introduce themselves as /Satoshi:0.16.3/, but always send corrupt getheaders messages. This is an example payload of the getheaders message that I'm getting from them (that's being at the block #561792): f9beb4d967657468656164657273000005040000fa8a778d7f1101001f0619a95d2dae0ffd58bb144890bff7b11ae2060ceb631e0000000000000000005f30eb8f449c54d2022691d295742c7a87d375c7785d0100000000000000000091fd7a78b9f8e3c297cb7b61d5b7858c1aeacfeabdbc0200000000000000000018a797686e559c65db551c494781c9d3376dadea6c1215000000000000000000467bff2cae14e26f0b078c4de62267e661536fda610022000000000000000000e286fad54eeca7795bbbefca420c197dc1a55fff78951d0000000000000000001d86a184718fc6c966490445845997a385b42241ef790600000000000000000074b5a970607dfd7efda26bc617dc4c7f8192b57368980c000000000000000000d3ae6ba3fe0389bf3d0581e8ff1dcd6feb873e4d020a15000000000000000000090ba32482c702f23f7c50297d4ed6327fd43f1602a71c00000000000000000062d04bf3ab1ce424641873e380b434190e357b509e401b000000000000000000c49a24ba246faee1c3ce6fa40ff19122a77515e542f10d000000000000000000624a3e2b2846e2a48084e895fa467595c623a5504f2e12000000000000000000bf8acf2c829eb75740f32049b7fd66641cd142dbf19c1900000000000000000043706c6d5e64b257d99fd059983b8abc209463c8f2641c00000000000000000053933c66aaec90c89e61ce2e169194de8bcd0636cb0225000000000000000000319c87b73707566073624974cf0f11aa225c1685480a060000000000000000008a9f417e2c7362d63e95d6fad7526d1601e169a26bfa250000000000000000003febcb780928a8f35fb988f1defa9df77b7c0009069b030000000000000000000054121e0127fd334e1a9676801ecb8daa0c3cd811580e0000000000000000002e1f62d6f9d8ff43317101bf4929c7e166b5baa95cf22b000000000000000000ea8db7544b14d5693e322f666f0f0b19a939d319390124000000000000000000cfdaac005703ce932ca7d955e21abc46f1c56db952ed150000000000000000000df113f8149bfe143bbc66539bff96a3b27cd797503b12000000000000000000b057a4a803cb6b66a05fd6614b95d68b2b2bdb8aced2010000000000000000008914d8bf2aa7bafd50c42fa04bd216dfe8d570570eee34000000000000000000abc75fe8fb567c21a355bd0c485e0a76d9861812d16f8c0000000000000000001906619a74e24c827959f87d62a8e522b18104c0c6fe0d040000000000000000201565e26b08dcae15c6f615cb26d43fda8ec590cba76e480000000000000000c853c6362816edcb8ef553e3c69faa452eac54c5829245eb018b916a000000006fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d61900000000000000000000000000000000000000000000000000000000000000000000000000 Having analyzing this payload: f9beb4d967657468656164657273000005040000fa8a778d
7f110100
1f
0619a95d2dae0ffd58bb144890bff7b11ae2060ceb631e000000000000000000
5f30eb8f449c54d2022691d295742c7a87d375c7785d01000000000000000000
91fd7a78b9f8e3c297cb7b61d5b7858c1aeacfeabdbc02000000000000000000
18a797686e559c65db551c494781c9d3376dadea6c1215000000000000000000
467bff2cae14e26f0b078c4de62267e661536fda610022000000000000000000
e286fad54eeca7795bbbefca420c197dc1a55fff78951d000000000000000000
1d86a184718fc6c966490445845997a385b42241ef7906000000000000000000
74b5a970607dfd7efda26bc617dc4c7f8192b57368980c000000000000000000
d3ae6ba3fe0389bf3d0581e8ff1dcd6feb873e4d020a15000000000000000000
090ba32482c702f23f7c50297d4ed6327fd43f1602a71c000000000000000000
62d04bf3ab1ce424641873e380b434190e357b509e401b000000000000000000
c49a24ba246faee1c3ce6fa40ff19122a77515e542f10d000000000000000000
624a3e2b2846e2a48084e895fa467595c623a5504f2e12000000000000000000
bf8acf2c829eb75740f32049b7fd66641cd142dbf19c19000000000000000000
43706c6d5e64b257d99fd059983b8abc209463c8f2641c000000000000000000
53933c66aaec90c89e61ce2e169194de8bcd0636cb0225000000000000000000
319c87b73707566073624974cf0f11aa225c1685480a06000000000000000000
8a9f417e2c7362d63e95d6fad7526d1601e169a26bfa25000000000000000000
3febcb780928a8f35fb988f1defa9df77b7c0009069b03000000000000000000
0054121e0127fd334e1a9676801ecb8daa0c3cd811580e000000000000000000
2e1f62d6f9d8ff43317101bf4929c7e166b5baa95cf22b000000000000000000
ea8db7544b14d5693e322f666f0f0b19a939d319390124000000000000000000
cfdaac005703ce932ca7d955e21abc46f1c56db952ed15000000000000000000
0df113f8149bfe143bbc66539bff96a3b27cd797503b12000000000000000000
b057a4a803cb6b66a05fd6614b95d68b2b2bdb8aced201000000000000000000
8914d8bf2aa7bafd50c42fa04bd216dfe8d570570eee34000000000000000000
abc75fe8fb567c21a355bd0c485e0a76d9861812d16f8c000000000000000000
1906619a74e24c827959f87d62a8e522b18104c0c6fe0d040000000000000000
201565e26b08dcae15c6f615cb26d43fda8ec590cba76e480000000000000000
c853c6362816edcb8ef553e3c69faa452eac54c5829245eb018b916a00000000
6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000
0000000000000000000000000000000000000000000000000000000000000000 ... it seems that there is an extra 24 bytes in front, with the actual (repeated) header of the message. Then the bytes "7f110100" - of the protocol version (weird value, but should be fine)... Then the rest seems to be a completely normal getheaders message, with protocol version 70015 followed by 31 locators and null hash stop. I just have two questions for people more familiar with bitcoin core. 1. Is it possible that the actual bitcoin core 0.16.3 would send such a corrupt message, at some circumstances? 2. What does (the recent) bitcoin core do upon receiving such messages? How does it interpret it? Because I'm just banning the node for sending me a corrupt message, but I'm not sure if that isn't too harsh. Below some IP addresses of nodes sending such a corrupt messages. GetHeaders: error parsing payload from 88.99.175.119:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 35.187.212.60:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 88.198.205.197:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 104.199.236.232:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 104.199.166.252:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 104.199.196.186:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 35.185.166.87:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 104.199.205.132:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 104.155.233.13:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 88.99.184.194:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 88.99.173.75:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 104.199.255.13:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 88.99.190.220:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 88.99.185.58:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 104.199.166.145:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 104.198.89.77:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 35.185.137.128:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 88.99.184.176:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 88.99.184.67:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 88.99.190.68:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 104.198.125.19:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 88.99.168.195:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 88.99.186.9:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 104.199.236.232:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 88.99.168.212:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 88.99.169.225:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 35.185.143.8:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 35.187.209.186:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 35.187.205.4:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 88.99.191.228:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 104.198.94.212:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 88.99.189.17:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 104.199.253.135:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 104.198.116.195:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 104.199.172.60:8333 /Satoshi:0.16.3/ EOF
GetHeaders: error parsing payload from 104.155.233.13:8333 /Satoshi:0.16.3/ EOF
I've never seen it being sent from any other node than one introducing itself as /Satoshi:0.16.3/ But there is many of them out there (the IP list above is just a fragment). |
|
|
|
I've noticed the recent core nodes (v0.16.0 or higher) by default introduce themselves with services bit 0x400 Then I read (in src/protocol.h) this means that the node only stores the last 288 blocks.. // NODE_NETWORK_LIMITED means the same as NODE_NETWORK with the limitation of only
// serving the last 288 (2 day) blocks
// See BIP159 for details on how this is implemented.
NODE_NETWORK_LIMITED = (1 << 10),
Is it true? Also BIP159 says "Status: Draft" and defines NODE_NETWORK_LIMITED as: If signaled, the peer MUST be capable of serving at least the last 288 blocks (~2 days). So I'm a bit lost here.. |
|
|
|
As the comments in this PR have been locked, I'd like to move the discussion here. Apparently I present a "misunderstanding of the Bitcoin system"  Well, please help me to understand it, then. I would like the supporters of this change to answer my question: Who, how and why defines (and guards) the consensus rules? Can you try to give me a "technical" answer? (as opposed to a "political" answer) |
|
|
|
|
What I have seen by monitoring the network is that 0.14.x software has been (so far) the fastest to relay blocks.
Which is understandable as it relays blocks before verifying it.
What is not understandable for me, though...
Why pre 0.13.0 software is faster in relaying transactions?
I know 0.12 got secp256k1, but 0.13 and 0.14 also had it...
So why is 0.12.x faster in relaying txs than any version that came later?
It is actually even more weird: it seems that even 0.10.x and 0.11.x are quicker in relying transactions than 0.13+
And these still used openssl for EC operations.
|
|
|
|
It's not an issue, but I find in intriguing and would like to understand the reason. When I draw a chart for each block that presents a fee (in SPB), in relation to how far the tx was placed inside the block, it almost always looks somehow like this:  What I mean is that the chart in general goes form the highest SPB to the lowest one. - which is understandable. But what is strange for me is that it isn't smooth. There are spikes - in some places inside the block you have a tx whose fee is "too high" for that place, but that is sort of compensated by a tx placed next to it whose fee is to low to end up there. So what is the reason for placing the txs like this? Is it because of the Child Pays for Parent feature, or is it something else? Sorry, I know I can figure it out by reading the code, but hope that someone can just help me here. I mean, by referring me to the specific code that is responsible for this behaviour. |
|
|
|
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 |
|
|
|
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)/
|
|
|
|
|
What does network protocol version 70015 indicate, as comparing to previous 70014?
Can you please refer me to a BIP number or something.
|
|
|
|
I remember Gavin Andresen saying that the serious bitcoin development debate is at the mailing list now, because the bitcointalk.org forum turned into something he didn't like anymore. Personally I like bitcointalk forum. It was started by Satoshi himself and there is practically zero censorship here, even if you say to the mod that he's an idiot. It's definitely my favourite bitcoin forum. Anyway, I sometimes read the mailing list. Now they have this thread there, about the user activated soft fork: http://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg04774.html USAF against the miners majority - for anyone who knows about how bitcoin works, it's obviously a crazy idea. But it's ok - kids should also have their time to speak and feel important, I really don't mind. Except that the kids seem to be establishing some kind of cartel, where they don't want to listen to the adults anymore... So here is the story from today. This topic I mentioned before, there was this man saying: There isn't a flag day to set. If the major economic organs like exchanges run
the BIP, non-signalling miners simply wont get paid (starting October 1st) and
their blocks will be rejected. Miners will have the choice to signal, or find
something else profitable to mine. In turn, this will trigger the existing
segwit deployment for everyone who has already upgraded to segwit compatible
node software (currently Bitcoin Core 0.13.1, 0.13.2, 0.14.0, Bitcoin Knots
0.13.1+, and bcoin) regardless of whether they run this BIP or not.
But yes, it goes without saying that this BIP would need to have buy-in from
major economic organs, especially fiat egress points, before being deployed.
Failing that, a second deployment of segwit with a flag day, or preferably
using the bip-uaversionbits-strong BIP9/flagday hybrid would be required. So then I tried to answer: You're insane, man.
If miners had to 'find something else profitable to mine', they'd just start mining
double spends depositing BTC to the exchanges that are trying to fuck them up.
There is absolutely no way the UASF can work.
Exchanges would be insane to even raise their support for it.
Stop wasting your time, for your own sake. Few minutes later I got the message from the mailing list: Your request to the bitcoin-dev mailing list
Posting of your message titled "Re: [bitcoin-dev] Flag day activation of segwit"
has been rejected by the list moderator. The moderator gave the following reason for rejecting your request:
"[No reason given]"
Any questions or comments should be directed to the list administrator at:
bitcoin-dev-owner@lists.linuxfoundation.org OK... maybe he didn't like me swearing... lets try again with a more kids friendly syntax: I think you don't realize what you are talking about.
If miners had to 'find something else profitable to mine', they'd just start mining
double spends depositing BTC to the exchanges that are trying to remove them from the business.
There is absolutely no way the UASF can work against the miners majority. ... few minutes later: Your request to the bitcoin-dev mailing list
Posting of your message titled "Re: [bitcoin-dev] Flag day activation of segwit"
has been rejected by the list moderator. The moderator gave the following reason for rejecting your request:
"In the name of Wu, this post shall not pass." In case you missed it: "In the name of Wu, this post shall not pass."Which brings me to the question: Who moderates bitcoin-dev mailing list?Why are the actual serious developers using this mailing list? What is so special about it and who do I have to fuck to get my messages through? |
|
|
|
Recently I see more and more nodes, introducing themselves as "/Satoshi:0.13.1/" but sending me sendcmpct message that is only 5 bytes long. Can anyone say if they are legitimate bitcoin core nodes, or just some other stuff pretending to be the latest release of core? What shall I do with sendcmpct message that carry only 5 bytes of data? Some example logs below 42314 139.59.208.241:8333 /Satoshi:0.13.1/ sendcmpct 0002000000
42314 139.59.208.241:8333 /Satoshi:0.13.1/ sendcmpct 0001000000
42453 46.101.99.121:8333 /Satoshi:0.13.1/ sendcmpct 0002000000
42453 46.101.99.121:8333 /Satoshi:0.13.1/ sendcmpct 0001000000
42454 46.101.99.121:8333 /Satoshi:0.13.1/ sendcmpct 0002000000
42454 46.101.99.121:8333 /Satoshi:0.13.1/ sendcmpct 0001000000
42698 138.68.66.47:8333 /Satoshi:0.13.1/ sendcmpct 0002000000
42698 138.68.66.47:8333 /Satoshi:0.13.1/ sendcmpct 0001000000
42866 139.59.209.199:8333 /Satoshi:0.13.1/ sendcmpct 0002000000
42866 139.59.209.199:8333 /Satoshi:0.13.1/ sendcmpct 0001000000
42923 46.101.109.46:8333 /Satoshi:0.13.1/ sendcmpct 0002000000
42923 46.101.109.46:8333 /Satoshi:0.13.1/ sendcmpct 0001000000
43048 139.59.157.246:8333 /Satoshi:0.13.1/ sendcmpct 0002000000
43048 139.59.157.246:8333 /Satoshi:0.13.1/ sendcmpct 0001000000
43513 138.68.64.28:8333 /Satoshi:0.13.1/ sendcmpct 0002000000
43513 138.68.64.28:8333 /Satoshi:0.13.1/ sendcmpct 0001000000
43788 46.101.228.246:8333 /Satoshi:0.13.1/ sendcmpct 0002000000
43788 46.101.228.246:8333 /Satoshi:0.13.1/ sendcmpct 0001000000
43997 139.59.208.241:8333 /Satoshi:0.13.1/ sendcmpct 0002000000
43997 139.59.208.241:8333 /Satoshi:0.13.1/ sendcmpct 0001000000
44088 188.166.161.228:8333 /Satoshi:0.13.1/ sendcmpct 0002000000
44088 188.166.161.228:8333 /Satoshi:0.13.1/ sendcmpct 0001000000
|
|
|
|
|
It's probably a known problem, so maybe someone could give me a hint before I start digging into the problem, trying to reinvent the wheel.
My client has no support for SegWit (yet).
When it parses new testnet blocks (ones that spend segwit outputs), it takes ages to process them...
Does anyone know what is going on?
|
|
|
|
|
Recently I've read somewhere that the way hash_serialized gets calculated has changed, but I just want to ask about the last version (not yet released):
How exactly is it calculated?
Specifically, can someone please confirm that I need to have the utxo records sorted, in order to calculate it.
How are they sorted?
Also, are there any plans to make this hash more open and verifiable, for a purpose of setting up fresh nodes with a snapshots of an UTXO database?
I'd imagine setting up a node with a snapshot of the coinstate db, without the need to build it up from the blockchain.
That'd save shit loads of time, bandwidth and disk space.
|
|
|
|
As I learned only recently one of the steps in a new block's verification is counting a total number of sigops inside the block - if it'd exceed 20000, such block supposed ot be rejected. So I've implemented this in my own software, but cannot find any reliable reference to make sure that I'm counting these numbers properly. Does anyone know any block explorer that would show number of sigops in each block? Or if not, can anyone confirm whether I've counted these numbers properly: Block# Block Hash Sigops
403908 0000000000000000067549f6a6a4590405161bd6773166cd00518f121e6961b5 5600
403907 0000000000000000019955303142ecd05a374a0657945b8b2d1b89fd10cb9f17 2635
403906 0000000000000000060d52b13b0cd892dbf986177c8f2d7fe3f652e9574fce04 4527
403905 0000000000000000026031da9dc81b633bf3c566ddfc85bef72216a33c2166ec 1516
403904 000000000000000004f2b65476bcf0b72d9846283b87b488dd6be0c5c8423d39 930
403903 000000000000000001ee250b7132b41ed068ab443465b1d2954350c2e034b93a 1170
403902 000000000000000004a983db2a27e573b2aa2501a904440a8a7a00058eabdbb9 1708
403901 000000000000000002f5b6d90cff1f4083271f5dfc607c72cc99b80355de01d3 723
403900 000000000000000001e5e0c849184c832968f220456731820107acde3c91ed6a 5709
403899 000000000000000001bf70c02bc4bc1c962e808d411b0a3a627a0acdabb7d4ba 3311
403898 00000000000000000388e1db2b93eb338a48eec7f5c554e7f25c5a260c164ffb 3733
403897 0000000000000000017bf7996829ac5939d24e5c23c50b14d5cc94e131a1d43a 4603
403896 000000000000000006670bd2ec8902308ac712eca9421538b631471b6b18e110 7197
403895 0000000000000000024767f99ac1028162b728debebde0864b5aa3d932855c69 8951
403894 000000000000000002b6b8f7de6485c5829622306197af41aa338f59b56d38eb 3049
403893 000000000000000000520b20ac8dfc6388e8afa071d55e8e8f338645cf3db7a3 2380
403892 000000000000000001f3b14dcbc09dfce73c77890f82f935dc5e90b9cea1f69a 1809
403891 000000000000000000c52f273c7382616fbc72ae9cd080bb4a2b52d8deb70d2f 2791
403890 0000000000000000022bb622accabc0b8739adafa425ed4a605b0164c5d81b7d 3029
403889 00000000000000000313a13e433822d39c9f7226bff7230f3d92e971faf1f46c 4483
403888 000000000000000004a4388ca15be3d5a49ef66960972e3baf9a9ed27a27ff20 5372
403887 000000000000000003dc28c943e06f97809194b0d5460d58267c92152c03fc70 5728
403886 00000000000000000453bf07533a0a66bb164571759d5cd289b1bea250be758d 6282
403885 000000000000000006675fdbd01884e44bb8a4c4636209709ee768d9990c3609 1094
403884 000000000000000003e477a5f58893daa99578a1dd87014661d7e85df8370ebe 602
403883 0000000000000000037398599c10b434976d5825244f3dfafda8dd851e9313cf 2682
403882 000000000000000002a7161e6ad70e45ca8eaaa97c9821e0edc51612e977119f 6604
|
|
|
|
No, I don't have one I was just wondering, because I know the UTXO db is a very important component of the bitcoin system and it is obviously going to be somehow profitable in a future to have it well performing. How would you imagine a database engine designed specifically for bitcoins UTXO db? I think it's very important to be able to browse through all the records in a shortest possible time. |
|
|
|
|
It used to be very easy to build it using mingw, but there have been some changes and now I cannot build it anymore.
At least not out of the box, as it requires "autoreconf" command, which my mingw+msys don't have.
Does anyone know an easy way to build the lib on Windows host, using msys/mingw?
|
|
|
|
It's probably something I'm missing, but I haven't been able to figure out why certain test vectors with MINIMALDATA flag are expected to return FAIL, in the test suite. I mean, I assume that all the script inside script_invalid.json are a failing ones - aren't they? Because if so, can someone please explain me why e.g. these ones are supposed to fail: ["0x01 0x81", "DROP 1", "MINIMALDATA", "-1 minimally represented by OP_1NEGATE"],
["0x01 0x01", "DROP 1", "MINIMALDATA", "1 to 16 minimally represented by OP_1 to OP_16"],
["0x01 0x02", "DROP 1", "MINIMALDATA"],
["0x4c 0x48 0x111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111", "DROP 1", "MINIMALDATA",
"PUSHDATA1 of 72 bytes minimally represented by direct push"], Which specific code triggers these failures? |
|
|
|
|
