I uploaded all changes on github -namecoinj. Is there a way to get the android build up to date on my s3 mini without rooting?
Install the apk. How have you been testing it? I just run it on my phone but the wallet stops syncing somewhere. At first it crashes at block 10k then it loads some more until it stops completely at some block (11964). Always producing ouOfMemoryError s. I will test installing the apk tomorrow see you then... It is possible that your phone simply doesn't have enough RAM and thus can't run the app. |
|
|
|
|
Do you have any specific requirements for the accounts?
|
|
|
|
I uploaded all changes on github -namecoinj. Is there a way to get the android build up to date on my s3 mini without rooting?
Install the apk. How have you been testing it? |
|
|
|
Awesome, thanks. I'll try building on my own machine again soon. Are you building against API level 14, as per the pom.xml?
I just used the version on his site with a logcat app and I did not see any errors. The github for the app has not been updated for a few days. Doesn't the pom.xml need to be changed to use wlcj and not namecoinj? He also already committed the changes to wlcj so I won't submit a PR. |
|
|
|
My phone made it past 10k, and is around 17k and syncing right now. I'll continue testing with adb.
Edit: I've fetched up to the second to last block. Was this version built before my last change?
you should just commit the changes to github and submit him a pull request to make sure that the changes are correct. I will also test the app on my phone. Edit: just ran the app and there were no errors. My working copy is a mess due to debugging code. I'd need to redo many of the changes cleanly to make a PR. When I get to my computer I can make all the changes she submit the PR. My code is relatively clean and I can do it quickly. Awesome, thanks! Just to confirm, with an up to date android build, you can sync to the last (not second to last) block? In that case, should we begin testing with real coins and various transaction patterns? It loads all the way. |
|
|
|
My phone made it past 10k, and is around 17k and syncing right now. I'll continue testing with adb.
Edit: I've fetched up to the second to last block. Was this version built before my last change?
you should just commit the changes to github and submit him a pull request to make sure that the changes are correct. I will also test the app on my phone. Edit: just ran the app and there were no errors. My working copy is a mess due to debugging code. I'd need to redo many of the changes cleanly to make a PR. When I get to my computer I can make all the changes she submit the PR. My code is relatively clean and I can do it quickly. |
|
|
|
My phone made it past 10k, and is around 17k and syncing right now. I'll continue testing with adb.
Edit: I've fetched up to the second to last block. Was this version built before my last change?
you should just commit the changes to github and submit him a pull request to make sure that the changes are correct. I will also test the app on my phone. Edit: just ran the app and there were no errors. |
|
|
|
|
You need to set the data directory to be the folder that contains the blocks folder.
|
|
|
|
You didn't mention any thing about post quality? If all are single line comments then no use of this senior account because you can't join any high paying signature campaign
I think the past quality is okay, although I am not a good judge if post quality. It had been a part of signature campaigns before so the post quality isn't too bad. |
|
|
|
|
I have a Senior Member that I would like to sell
Posts: 300+
Activity: 300+
Potential Activity: 350+
Registered: 2013
Feedback: neutral
I am asking for 0.23 btc for this account. The private key for an address will be added for an additional 0.01 btc should the buyer want it.
Escrow is required. I will provide the signed message to the escrow.
|
|
|
|
I must be missing something, but I thought the fork depended on blocks
mined, not on number of nodes.
So maybe the anti-XT party could spend some electricity to
mine "fake" XT blocks in order to produce illusion of 75% goal
reached. But would that really accomplish anything? Undecided miners might
still jump on the bandwagon.
Well that will not cause premature >1mb blocks, as they are scheduled no earlier than 11 Jan 2016. However it could cause the fork to occur on 11 jan 2016 without consensus. If for example 50% of the miners were XT, 25% NotBitcoinXT and the rest Core, then the fork could happen and spawn two chains with equal hash power. This could be detrimental to Bitcoin has we have previously established that such a fork is not a good thing. |
|
|
|
Let's not argue.
I am looking at some random blocks. What I see is that a single transactions is a
hash -> Don't know how to compress
Impossible without losing data. index -> why not sort by time, input etc, something 'drawn' from the data?
What index and what sorting are you taking about? We have inputs and outputs. For example, frequently we have inputs from the same origin, why not add them up for storage?
What do you mean add them up? New transactions need to be able to reference the inputs so simply "adding them up" won't allow clients to create transactions. Just looking at a set of blocks make we wonder why we can't map them in a way that we just cut of all the leading zeros. ++
That could be possible but how much space will that really save? |
|
|
|
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.
|
|
|
|
|
Show Posts
