https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki"Activation is achieved when 750 of 1,000 consecutive blocks in the best chain have a version number with bits 1,2,3 and 14 set (0x20000007 in hex)." So, what will happen if NO XT miners start setting those bits only to activate prematurely XT? Without the needed hashpower, XT will become surely an altcoin with near-zero value? Which is the goal of this or to cause confusion that forces an abort. But then what happens if a lot of xt miners are also producing blocks to the point that the forked chain had enough halshpower to survive? |
|
|
|
You need to add the flag -datadir=<path to directory> to every bitcoin-cli command |
|
|
|
Older blocks may no longer be considered valid blocks under new rules - I can't believe that, older blocks are valid because they exist and have been confirmed everything else would contradict immutability. 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. - The version number is a variable(!), every miner is free to choose whatever she wants. If what you say is true, somebody could create quite a mess with sending an old version number. In such a case we should remove it as bug urgently. 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.
- They can also facilitate forking, again, there are clearly different versions being developed right now. Maybe, we have only a very narrow window open to make such changes to the block layout. Once there are 5 different implementations out there it will be impossible to even change such a small matter. Clearly you have not read the documentation. Historical blocks of older version numbers are still valid and may be validated inner different rules. At a certain point old version numbers are considered invalid so blocks with older versions are not valid and discarded by the client. Any version number that is not defined in the client will be validated as the current version which is why xt blocks can currently be accepted by Bitcoin core.
- How come? The header clearly not.
- Also, from what I read the transactions aren't either.
Thus, most of the volume is uncompressed.
However, you are right, compression would require more CPU cycles, but simple reductions could come at a very low cost of maybe 0.1% performance. Nothing in comparison to the saved bandwidth and HDD space.
The hashes cannot be losslessly compressed because hashes are random. I'd they are look say compressed them data is losses and hairs won't match. |
|
|
|
It seems like the second block has been mined aswell looking at this : http://xtnodes.com/xt_blocks.php , when we are supposed to upgrade to XT though ? I know it's on January and stuff however do we need 75% nodes running or we need 750 block mined from 1000 750 blocks mined from 1000. Looong time to go... Funny thing, this two mined blocks won't even count. It dosen't make sense then , why would they said it should stay up for two weeks . If blocks are mined then it's done ... so why the wait of 2 weeks  or both nodes & mined blocks should be available You're not getting it. It's not done. 750 blocks must be mined in LAST 1000, to allow fork to happen. This two mined blocks won't even count, as the window of 1000 blocks is moving. Then there is also a grace period of two weeks to get everyone to switch to XT before that actual fork and creation of a greater than 1 MB block. |
|
|
|
the real problem will be when bitcoinxt gain 30-40% of the mining bitcoins. Then we will a disaster and that will be the most dangerous momment of bitcoin. I think you dont need to have a 75% of the bitcoin network to create a fork a 51 is enough to run a pararrel system.
BitcoinXT is programmed to fork when 750 of the last 1000 blocks are XT blocks and it is january 11 2016 or later. The fork won't happen until that moment, it won't happen when it is at 51%. Of course, with NotBitcoinXT, then it could happen earlier and then both BTC and XT are going to die when there is a fork without consensus. |
|
|
|
No. We really don't.
If there is a fork, then one or the other of the two chains dies within a day. Whatever is left is BTC.
That was the case in with the previous forks where we had almost 100% consensus before the chain was forked. We now have two people and some followers that try to force the majority to accept their change package. Several people and some pools will not switch to the BXT forkcoin or use both coins BTC and BXT. There are good chances that we will continue with two chains. If this is established as a good way to push changes into the market, we might see several additional chains in the future. This is fine with me. Everybody and every group of people is free to use their own set of consensus rules and fork the coin. But as long as the original coin is alive the forkcoin should not use the name of the original coin. The only way that I can see that we end up with two chains is if the fork occurs without consensus. With BitcoinXT, the fork is programmed to occur with consensus, therefore that fork becomes BTC. If it occurs without consensus (which is what NotBitcoinXT is doing) then we will end up with two chains and both BTC and BXT will be discredited and then both will crash and die. |
|
|
|
It sounds like a good idea, but I suspect theymos wouldn't be interested in implementing it mostly because it requires the forum to hold money on behalf of others. If he somehow lost control of the funds, would he be liable to pay back all lost funds? I don't think he'd want to get mixed up in something like that. Also, if the website started to hold bitcoin (although it would probably be a small amount per user, but there are well over 500k users on the site) it would become a bigger target for hackers if there is a monetary incentive.
Tips don't seem to be sent very much (once and awhile on /r/Bitcoin, but not very often from what I've seen), and for the amount of work it would be to implement something like that and try to secure it all I don't think it would be worth it. The current situation of sending a tip to the address listed on a user's profile seems easy enough for me.
What are you talking about? Why even forum need to hold money from tips in the first place? I will be p2p tip service. If you state your BTC address in the options, you will gain tip button, and then all tips will be send to you directly. There is no need for forum moderation over this feature. That's basically how it works now, minus the tip button. Instead, you go to a user's profile, copy the bitcoin address they have listed and send the funds there. Like I mentioned before, I don't think it would be worth it to implement a tip button to save a couple of seconds when a) tips are rarely sent around here and b) users can already put a tip address in their profile for everyone to see and send funds to if they wish to. The proposed tip button wouldn't make it much easier to see their public tipping address. The button could basically just be a uri link that opens up whatever bitcoin client with all of the details set (except amount) for the tip. The user just needs to enter the amount and hit send. The difference would be instead of having to manually create the link and put it in the profile, the forum could simply make the thing automatically for users that set the address in their profile. |
|
|
|
|
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? |
|
|
|
|
Show Posts
