|
I think the point of the version numbers is to define which consensus rules a block follows. Older blocks may no longer be considered valid blocks under new rules, but with the version numbers, clients can identify which rules those blocks follow. E.g. version 2 blocks did not necessarily include transactions that followed the BIP66 rules but version 3 does. If the version numbers did not exist, then we would have an issue where some v2 blocks are no longer valid under v3 rules and the clients would get all screwed up because they have historic blocks that don't validate.
Version numbers also help to facilitate miner voting. Miners voted for using BIP66 rules by producing v3 blocks. BitcoinXT nodes vote for BitcoinXT by producing blocks with 0x20000007 set as the version.
|
|
|
|
I managed to sync successfully up to height 22103, by modifying org.bitcoinj.core.Transaction. Edit: Now synced to 22194 before crashing. I think I've managed to sync almost all of the chain, however it's rejecting the last block with an invalid difficulty. The C++ client accepts it, and the two clients are in agreement about difficulty. The parse() method in that class should now be: @Override
void parse() throws ProtocolException {
if (parsed)
return;
cursor = offset;
version = readUint32();
optimalEncodingMessageSize = 4;
// First come the inputs.
long numInputs = readVarInt();
optimalEncodingMessageSize += VarInt.sizeOf(numInputs);
inputs = new ArrayList<TransactionInput>((int) numInputs);
for (long i = 0; i < numInputs; i++) {
TransactionInput input = new TransactionInput(params, this, payload, cursor, parseLazy, parseRetain);
inputs.add(input);
long scriptLen = readVarInt(TransactionOutPoint.MESSAGE_LENGTH);
optimalEncodingMessageSize += TransactionOutPoint.MESSAGE_LENGTH + VarInt.sizeOf(scriptLen) + scriptLen + 4;
cursor += scriptLen + 4;
}
// Now the outputs
long numOutputs = readVarInt();
optimalEncodingMessageSize += VarInt.sizeOf(numOutputs);
outputs = new ArrayList<TransactionOutput>((int) numOutputs);
for (long i = 0; i < numOutputs; i++) {
TransactionOutput output = new TransactionOutput(params, this, payload, cursor, parseLazy, parseRetain);
outputs.add(output);
long scriptLen = readVarInt(8);
optimalEncodingMessageSize += 8 + VarInt.sizeOf(scriptLen) + scriptLen;
cursor += scriptLen;
}
lockTime = readUint32();
optimalEncodingMessageSize += 4;
if(this.version==2) {
refHeight = readUint32();
optimalEncodingMessageSize += 4 + 4;
}
length = cursor - offset;
} Here's the new error: org.bitcoinj.core.VerificationException: Could not verify block f26842324aca22db7c16ddf087277ee99117d0fa29ca5d5f6eaaaf4d42d9d8f0
v1114369 block:
previous block: c85bfc960881fa6cfa833feef10e2842fe7b56f56aa962fdd0e2300b59c4da3e
merkle root: 505a544293220d73c2f1b1ca3285906828fc8abcc39aa41a3f4155fc347b3c3a
time: [1440012311] Wed Aug 19 15:25:11 EDT 2015
difficulty target (nBits): 436643261
nonce: 0
Merged-mining info:
version: v1114369
time: [Wed Aug 19 15:25:11 EDT 2015] Wed Aug 19 15:25:11 EDT 2015
difficulty target (nBits): 436643261
nonce: 0
Network: org.worldleadcurrency.production
parent block coin base transaction:
679a73c3467721d6fc3ffdcf6865da6b0283d50664b1d2914d67b111bbe072fd: Unknown confidence level.
== COINBASE TXN (scriptSig PUSHDATA(3)[a4a705] PUSHDATA(44)[fabe6d6d7f15c02dd05c3eacefde83dd74b0f9b5ed7155c9ec92ef280acdda2bacd1f5c32000000000000000]) (scriptPubKey DUP HASH160 PUSHDATA(20)[3d47986f727402feb3df5134dff583af4ace8074] EQUALVERIFY CHECKSIG)
coinbase link:
hash of parent block header: 000000000000023a97f467afb051ac1480e27bed9788e8fdb9ac2d892614f551
parent block header:
v3 block:
previous block: 00000000000000000759c455cd9b9402a461885fe76e0261092a5cd7a575038d
merkle root: cac502a2d3a6865430f959b445ff563b4bcd49f60ab9ad8579d6ab54ff829108
time: [1440012417] Wed Aug 19 15:26:57 EDT 2015
difficulty target (nBits): 404020484
nonce: 3237608803
with 1 transaction(s):
505a544293220d73c2f1b1ca3285906828fc8abcc39aa41a3f4155fc347b3c3a: Unknown confidence level.
== COINBASE TXN (scriptSig PUSHDATA(4)[bda5061a] PUSHDATA(1)[01] 2) (scriptPubKey PUSHDATA(33)[02bc41065c462d75844cf77624b712a29064cd21630e9b8c3c68990e4881a9b58e] CHECKSIG)
at org.bitcoinj.core.AbstractBlockChain.add(AbstractBlockChain.java:286)
at org.bitcoinj.core.Peer.processBlock(Peer.java:872)
at org.bitcoinj.core.Peer.processMessage(Peer.java:360)
at org.bitcoinj.core.PeerSocketHandler.receiveBytes(PeerSocketHandler.java:178)
at org.bitcoinj.net.ConnectionHandler.handleKey(ConnectionHandler.java:217)
at org.bitcoinj.net.NioClientManager.handleKey(NioClientManager.java:75)
at org.bitcoinj.net.NioClientManager.run(NioClientManager.java:111)
at com.google.common.util.concurrent.AbstractExecutionThreadService$1$2.run(AbstractExecutionThreadService.java:60)
at com.google.common.util.concurrent.Callables$3.run(Callables.java:93)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.bitcoinj.core.VerificationException: Hash is higher than target: 13e6b9f88b5a8bd9a36adb475588d6108d8594b8eb37c5122ae70d3c4beface7 vs 6a5bd0000000000000000000000000000000000000000000000
at org.bitcoinj.core.Block.checkProofOfWork(Block.java:766)
at org.bitcoinj.core.Block.verifyHeader(Block.java:886)
at org.bitcoinj.core.AbstractBlockChain.add(AbstractBlockChain.java:397)
at org.bitcoinj.core.AbstractBlockChain.tryConnectingOrphans(AbstractBlockChain.java:825)
at org.bitcoinj.core.AbstractBlockChain.add(AbstractBlockChain.java:424)
at org.bitcoinj.core.AbstractBlockChain.add(AbstractBlockChain.java:275)
... 9 more
Yup. Getting the same error as well. I think I know what the problem is. For some reason (can't find it yet) it sets all of the headerParsed boolean to true except for the last block. Then, for the last block, it parses the header, and finds that the hash of the header is not less than the target. To show this, if you convert the last block's header (22214) to a decimal integer, you get f76c22e3179b613366e6098d5a963df3147a140684377cb04babfa31615e839d -> 111912333864832649963788629443113007904287670404150873962674491627731299500957 and the bits (1a6a5bd) is 6a5bd0000000000000000000000000000000000000000000000 -> 10681984318408322427192353450286343108761369678138805919416320 For a valid block, subtracting the block integer from the bits integer should result in a positive number (hash is less than difficulty). However, in this block (and many others) the hash is an integer that is GREATER than the bits. Therefore I conclude that there is something wrong with how WLC is merged mining its blocks. Of course this could all be wrong. Please not that I have not yet taken a look at the c++ code yet, but I am running the client.
Nevermind, the above is semi wrong. I forgot that merged mining checks the parent block hash and not the actual block hash. The problem is that it is not setting the parent block hash as the hash, but is using the normal hash. The problem is specifically at the if block at line 732 in Block.java. I am investigating to see what is causing it to fail. |
|
|
|
BIPs 100-104 demonstrate the devs have not been sitting on their hands. Please calm down and stop exaggerating.
The debate is technical, regardless of your desire to make it a popularity contest:
At this point, the debate is no longer technical. The consensus is generally to raise the block size, as shown by BIPs 100-104. The problem I see is the way to do so which is more political. It is basically a contest between which BIP will actually get used. Of course, XT has a head start since it already has an implementation while I have not yet seen any implementation of the other BIPs. |
|
|
|
As far as I can see the argument is already over if the anti-XT crowd feels it is so certain to lose any fair contest that it will resort to tactics like this.
Seriously. They screamed all rational discussion about ending the block size limit to a standstill even though ~75% of the users and an even greater fraction of the miners are solidly in favor of >1MB blocks, and now that they are facing an actual implementation of a client that will hardfork to >1MB blocks they're trying to sabotage the consensus process rather than allow consensus to be decided by adoption?
At what point do they admit they've already lost?
If ~75% of the users and even greater fraction of the miners are solidly in favor of >1MB blocks, how come XT doesn't have 75% of the nodes and a large portion of the blocks aren't blocks with the XT version number? |
|
|
|
I think I may have found where the problem is, but I will need to do some testing. This is just from looking at the code. I think it has to do with VarInt and the readVarInt() method in message.java. This method is called to get the length of the array and I think it isn't doing something correctly which causes the length to be too small. I need to check this out with debugging though.
Hexafraction, can you send me the main class that you are using?
readVarInt isn't the culprit, as far as I can tell. It's being called when the array pointer is already pointing in an invalid location. I'll pastebin the main class I'm using shortly. Edit: http://paste.ubuntu.com/12112739/It's nothing fancy, but it fetches blocks and gives me a debuggable program. Chain is static so the debugger can easily access it for expression evaluation and conditional breakpoints. I think the error is definitely in VarInt or readVarInt because at line 259 of Block.java returns number of transactions to be 132 when there is only 1 and in line 590 of Transaction.java it also returns 132 from readVarInt(). The specific ArrayIndexOutOfBounds error is caused by the length being too long, which is also set by ReadVarInt(). I am going to take a look at VarInt to see whether I can find the problem. Why is reading varints for the last thousands of blocks OK? Is the format different for that specific piece of data? Or are the parser reads misordered, misaligned to the actual structure, or calling for a varint where the format isn't a varint? The data for block 11418 is different because it is merge mined, which is probably causing the problem. Actually, it might not be VarInt but the offset passed into it. After a little more analysis, it looks like the offset is not set correctly, which is causing VarInt to return incorrect numbers. I could be wrong. |
|
|
|
I think I may have found where the problem is, but I will need to do some testing. This is just from looking at the code. I think it has to do with VarInt and the readVarInt() method in message.java. This method is called to get the length of the array and I think it isn't doing something correctly which causes the length to be too small. I need to check this out with debugging though.
Hexafraction, can you send me the main class that you are using?
readVarInt isn't the culprit, as far as I can tell. It's being called when the array pointer is already pointing in an invalid location. I'll pastebin the main class I'm using shortly. Edit: http://paste.ubuntu.com/12112739/It's nothing fancy, but it fetches blocks and gives me a debuggable program. Chain is static so the debugger can easily access it for expression evaluation and conditional breakpoints. I think the error is definitely in VarInt or readVarInt because at line 259 of Block.java returns number of transactions to be 132 when there is only 1 and in line 590 of Transaction.java it also returns 132 from readVarInt(). The specific ArrayIndexOutOfBounds error is caused by the length being too long, which is also set by ReadVarInt(). I am going to take a look at VarInt to see whether I can find the problem. |
|
|
|
|
There will be a problem with having two nodes on the same data directory. It is not possible since the first one will lock the directory. Also, for some reason using a datadir from windows on linux and vice versa always cause a reindex of the blockchain.
|
|
|
|
How does the coin format the merge mining data in the block? Also, is there a block explorer I can use for this coin? That would make it much easier to figure this whole thing out.
The Blockexplorer can be found at: 109.73.173.119:81 (the balances are in satoshi not in wlc). I try to find out more about the merge mining data in the block, can you specify a little bit what information you need? Thanks. The blockexplorer helps. It gives me the data I need, which is the raw format of the blocks in a human-readable format. |
|
|
|
|
How does the coin format the merge mining data in the block? Also, is there a block explorer I can use for this coin? That would make it much easier to figure this whole thing out.
|
|
|
|
So I have done some debugging and I found the problem to be at Line 505 in message.java with the line System.arraycopy(payload, cursor, b, 0, length); which is called at line 43 of TransactionInput.java. It appears that the the length passed in is too long since the cursor + length exceeds the length of payload. Either the length passed in is too large, or the cursor is positioned too far back. I will investigate some more the find out. Edit: The length of the payload is 10430, the cursor is at 10177, and the length is 34966. 34966 + 10177 =45143 > 10430. |
|
|
|
what bitcoin xt anyone can explain ? look like bitcoin clone
It is a client forked from Bitcoin Core that intends on hard forking the blockchain to increase the maximum block size from 1 MB to 8 MB. It is a very controversial topic as of now. |
|
|
|
satoshi@vistomail is a fake address
It is actually not since he used that email address for the very first announcements on the Bitcoin mailing list. It is likely to be a fake email and someone simply was able to get into that email address. Without a signed message with either PGP or known Satoshi addresses, this will considered to be fake. If it is Satoshi, he should see that people want a signed message and will provide it to prove his identity. |
|
|
|
So we have all heard of BitcoinXT which implements BIP 101. But are there other clients that implement the other proposals for larger blocks? AFAIK these are the BIPs Are there any known implementations for this besides BIP 101? Where can we find this code and is any of it ready for use? |
|
|
|
|
The implications that I can think of are the consequences of a premature fork. If a large portion of the economic majority use BitcoinXT, while another portion uses NotBitcoinXT, it could make it seem like there is consensus for the fork, when there actually isn't. Then it would cause the fork to occur, split Bitcoin into two chains and now we have a big problem on our hands. As has been long established, hard forks without consensus is a terrible idea.
Another things is that people who aren't using XT see that it looks like XT is gaining support and nearing the fork point (due to NotBitcoinXT) then they might jump to using XT because it seems like XT will cause a fork. This could unintentionally gain support for XT.
Lastly, it could also completely prevent the fork outright if Gavin and Hearn realize that NotBitcoinXT could cause forking issues because of forking without consensus. Then they might cancel or postpone the fork in order to actually prevent Bitcoin from dying because of a fork.
|
|
|
|
So it's not an XT block, it's just another bitcointalk.org 'Gavin-ista' trying his best to spread a bit of FUD on the forum? Why do ppl here always take some post as fact without even checking it first? This is why the FUD against BitcoinXT went out of control here. I don't really understand this. Is 536870919 the version number for BIP101. If not, what would be the right version number? I believe the version number for BIP101 is 4. But if that site only checks if it's higher than 3, then 536870919 fits as well, though not being an XT block. That's a theory, though. It actually is , which is the hex number 0x20000007 decimal form. see https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki#Deployment for how the deployment plan is to work. |
|
|
|
sorry I am very simple minded.
If I currently own 1 btc, does it mean that I also own one XT?
Yes, but only after the fork happens, which at its earliest date is 1/11/2016 If I have BTC on exchange I dont own XT.
Unless that exchange is using both XT and Core, which is unlikely If I will buy 10 btc only next year I will not own XT at all.
Only if the fork has happened. There is no guarantee the fork will happen by next year. But if it does happen and you buy 10 btc, then you probably won't have XT. It is possible for you to also get Xt if the inputs of the transaction for the 10 btc were from before the fork. If that happens, then you could have both XT and btc since the transaction would be valid on both chains. Also, keep in mind that if the fork occurs with consensus, then it is very unlikely that any major exchanges, miners, or businesses will continue to use Bitcoin Core on the old chain and will then switch to the XT chain which will be called Bitcoin. |
|
|
|
|
I have thought about this for a little bit, and I have thought of two scenarios that could happen because of NotBitcoinXT
Scenario #1: Some people (a small percentage, less than 10%), including miners and exchanges, use BitcoinXT. NotBitcoinXT gains enough usage to cause a fork. Those 10% using XT are forked, while everyone else continues on normally. Some business is disrupted, but not too majorly and those XT users abandon XT and return to Bitcoin Core and your plan worked to maintain the status quo.
Scenario #2: A large portion( around 50%) of the users are using XT, and some more people use NotBitcoinXT which causes a fork. Now half of the Network is one the XT chain, and the other half on the Core chain. There are essentially two Bitcoins because the XT chain will continue to call itself Bitcoin since it was supposed to be a fork with consensus. Users will be frustrated because there are two coins called Bitcoin but you can't know which one to use. Business are confused and get angry customers because of the two chains, and new users don't know which one to use. lot of users and businesses stop using Bitcoin due to the hassle involved with trying to sell things with Bitcoin and two chains. Then they leave and don't come back because of this massive fuck-up and Bitcoin is Dead. Also, malicious users will have both clients, and get double their coins and attempt to sell to get the most profit.
Scenario #3: Ntohing happens and neither XT nor NotBitcoinXT gains enough traction to cause a fork.
Also, if people start to see XT to appear like it is gaining traction(when a lot of it is NotBitcoinXT nodes) and nearing the fork point, it might actually cause more people to jump to XT in order to stay in business. After the fork scenario two happens and shit hits the fan.
So again, please tell me how causing Scenario #2 is good? Or are you trying to go for Scenario #1?
|
|
|
|
NotbitcoinXT is not only useless but even more dangerous than XT itself as it gives false market indicators that could lead to an unnecessary forking or bad forking timing. This war mongering attitude is the only dangerous and childish behavior in this debate.
Nobody cares about your lulzy, incomplete attempt to rehash of the block size debate, so I deleted it. The entire point of NotXT is to give "false market indicators that could lead to an unnecessary forking or bad forking timing." That's why it exists. That's why we love it. How could you not understand that by now? We are leading XT into an ambush, wherein it will be contained and exterminated. Isn't that wonderful, and hilarious?  I'm sorry, perhaps I'm a litttle slow, but I still don't understand how causing a premature fork is good for Bitcoin and maintains the status quo? Wouldn't a fork create two blockchains with some people on one and others on the other. If exchanges and miners don't specify which blockchain they are on, then users get confused, new users are even more confused, and people stop using Bitcoin. People then stop using Bitcoin both because of the confusion, and the fact that two of them now exist completely discredits Bitcoin. So not only is XT discredited and abandoned, but so is Bitcoin. So please explain to me how a premature fork is actually good since it has long been established that FORKING WITHOUT CONSENSUS IS NOT A GOOD THING which is what this client is doing. |
|
|
|
|
I think I may have found where the problem is, but I will need to do some testing. This is just from looking at the code. I think it has to do with VarInt and the readVarInt() method in message.java. This method is called to get the length of the array and I think it isn't doing something correctly which causes the length to be too small. I need to check this out with debugging though.
Hexafraction, can you send me the main class that you are using?
|
|
|
|
Signature validation does not take 24 hours. What exactly are you talking about? Are you talking about validating the blockchain?
Yes, isn't most of the indexing\reindexing overhead due to signature validation? No. I don't think it is because the only thing with signatures are transactions. I think it is actually verifiying each block and transaction to match the consensus rules. Everything must be in the right format, and then the client uses the data given in each block and transaction to calculate the hashes and checks if it matches. For example (overly simplified), in a transaction, it must verify the signatures match. Then it must hash the entire transaction and the hash should come out to be the transaction id. If it doesn't match, the transaction doesn't validate. Then for blocks, it must hash every transaction together, which in some blocks can be more than 1000, and it gets the merkle root. Then it must combine the data in the header such has timestamp, nonce, and whatever else and get the block hash. If the hash it gets matches the hash it was given, the block validates. The reason this takes so long is not because hashing is slow, but because of the sheer size of the blockchain. It must validate every single block it receives, from block 0 to 370298 and beyond. This is what takes the most time. The process can be sped up with faster processors to do all of that hashing, which is why different computers take different times to validate and index the blockchain. |
|
|
|
|
Show Posts
