Is there no cross compiling? |
|
|
|
|
If you have time, could you write up instructions on the entire release process for building and packaging releases? I am trying to figure out how to do gitian builds with armory but I can't figure out how releases are currently being built and packaged.
|
|
|
|
It's obvious more than 50 percent of the Bitcoin hashpower is in the hands of chinese operators. in the last week the the situation escalated because of the near halving event.
Why is it a problem that the hash power is in a group of people's hands? Just because those people are in the same group does not mean that they are working with each other to create some evil plan. Should we consider a fork to SHA-3 even if the price will crash to double or maybe single digits afterwards?
No, because that fork would no longer be secure. Forks trigger with miners, and the miners would not want to fork to something that would render all of their equipment obsolete. Then that fork would be reliant on a much much smaller hashrate as the new miners would be mining with GPUs or CPUs. Or if they did agree, then in the months before hand (because such a hard fork would need to be announced and planned way ahead of time) they would work on getting equipment set up so that when the fork does happen, there is essentially no difference in their stake of hash power. The only difference would be that other users would then be able to join and mine as well and the entry barrier would be lower. IMO the only good reason to move to another algorithm would be if that algorithm was quantum resistant and that SHA256 was determined to be unsafe. That would be if a vulnerability was discovered in SHA256 which would give people unfair advantages in mining, e.g. preimage attacks or hash collisions. |
|
|
|
|
Not true, modern Bitcoin Core forks and Bitcoin Core itself is not affected by this vulnerability. Those articles are simply spreading fud.
|
|
|
|
Thank you for your help. I think it is just a signature. Very weierd, because he clearly states that he has sent bitcoin  I see 0 to mix PGP into this. Just ask him the TXID if he did send it. I'm assuming you sent him a BTC address and he is to send BTC to that address. No Bitcoin is going to go through PGP, you can't import it into your wallet, he has to sign and send from his wallet. I very much doubt he would instead send you the privkey for you to access the BTC, so PGP has no place here.  The attached file looks like a signature. I guess it doesn`t have anything to do with btc. I must have missunderstood. That file is just a signature for the email itself. You can verify the authenticity of that email and that it was actually him who sent the email. As for the bitcoin though, the attachment has nothing to do with that. You just need to wait for him to send bitcoin to your donation address. |
|
|
|
|
Your armory folder seems oddly large. Mine only takes up 66 Gb. And your bitcoin folder seems oddly small, mine takes up 80 Gb, but it should be around 60-70 Gb (mine is bigger because I have the txindex enabled.
|
|
|
|
Well, I came here to self admit an alt but I see that I was already spotted, not that I was trying to hide it anyways. Here is the proof for those who want it. It is signed with 1At6EhbjN8BLCJz4pVAjsFcNzhzxQmXrwZ which is in the profile of achow101 -----BEGIN BITCOIN SIGNED MESSAGE-----
Comment: Signed by Bitcoin Armory v0.93.3
Today is 2/15/2016. I, Knightdk, am admitting that achow101 is my alt.
-----BEGIN BITCOIN SIGNATURE-----
HGyp8lC+/Chdksltz8I/ZjNN5yL+EpeMLsd8vzUXEfYq6eRmIkOMeaZWXTyJN+CT
NjyKfu+6f4cknJwyDyP03c8=
=3WVL
-----END BITCOIN SIGNATURE-----
Also, what's up with this (bad copy-paste on the last three lines?): |
|
|
|
In the past 30 days, we've seen several blocks with more than 1,500 transactions included. With the current 1 MB limit, it means the average transaction must be below 666 bytes to fit.
Well, I made a transaction today, and I discovered it was 1,481 bytes. I'm very sorry. Other BTC users will have to make smaller transactions so that another 1,499 can fit into a single block.
This just shows the block size issue is very real, and that it needs to be solved as soon as possible.
The average transaction size is about 600 bytes (see http://statoshi.info/dashboard/db/transactions?panelId=2&fullscreen), transactions like your are outliers. |
|
|
|
Dont look at the length of the post for determining post quality, people can talk for paragraphs without it being constructive. I've seen that the account price checkers usually look at post lengths to display a post quality, but i usually just ignore that.
Indeed they do, as post quality is a relatively important part of an account's value. Most decent sig campaigns will not accept users with low post quality. Thus those sites (including mine, http://www.bctalkaccountpricer.info/) have a post quality check as part of the price. The problem though is objectively determining the post quality of an account. What I determine as a high quality post may not be what you consider as a high quality post. A bot most certainly doesn't have a mind to think subjectively like that short of it being an AI, so the only solution to objectively determine post quality is to do character count. However, when doing character count, my site only checks the unquoted text, so huge text pyramids aren't included in that count. I don't know if any other site does that. |
|
|
|
Geez it looks like there are bigger tradeoffs than I thought. So what about backups? Since Core doesn't allow HD wallets, every time you create a new address, you need a new backup (and everytime you pay or receive you should be using a newly generated address, so me personally I do backups every 2 week or month). So if I want to use one of those backups on the Bitcoin Core installation (the one I used originally to create said backups), I would need to re-download the entire blockchain? That doesn't sound pretty good, unless I've understood your explanation incorrectly.
I think I will stick to full node until I understand all the tradeoffs.
You clearly are not understanding all of the tradeoffs. Please read the post below the one you quoted where I explained how most of that was wrong. 1) The wallet in Core is still too minimalistic, it doesn't even allow you to order your receiving/sending addresses nicely in groups, or in order of creation etc, only by of alphanumerical order, so you end up with a mess since it's recommended to use 1 address each time.
You can group your receiving addresses in accounts. Don't know if it is supported in the GUI. haven't used the GUI for years, but I do use accounts a lot. The accounts isn't available in the GUI and AFAIK accounts are slated for removal soon. 2) The fact that you have to use an address each time is in itself an annoyance for noobs. Im wishing in the future stuff like BIP47 can solve this? Since I've heard HD by default is not possible with Core?
You don't have to use a new address each time, but it is best practice no matter which client you use. And any decent wallet will send change to newly generated change addresses unless you go through some options to specify otherwise. Even with HD wallets, you will still be using a new address for pretty much every transaction. 3) Then we have the need of doing backups for each single new address we make. Obviously it's too paranoid, but every month or so, you would need to copy your current wallet.dat to your backup devices since the backup devices would lack the generated addresses during that period.
Nah, the default keypool contains 100 addresses. You can make 100 transactions with change or recieve to 100 new addresses before you have to back up again. You can make the keypool larger if 100 is not enough. There is work on making Bitcoin Core use HD wallets so it will also make this a non-issue at some point in the future. |
|
|
|
What's the "merchant" and the "normal" RadioBoxes for exactly ? which one should I select in my case ? (this account)
Merchant makes the info that is displayed only display some of the details of the account and it does some stuff to make it harder for other people to identify which account's price has been estimated. This is useful if you want to sell an account. Normal is just normal, it displays all of the info that was gathered and calculated. You can't switch between normal and merchant. If something is requested as merchant, then the data that is gathered, calculated, and stored is for the merchant option only and it cannot switch to be displayed as normal. |
|
|
|
|
First of all, your fee is a bit low. The transaction is a rather large transaction so it requires a higher fee. Secondly, you have a dust output. One of the outputs in that transaction is 0.00001061 which is less than the current dust threshold of 0.00002730. Transactions with dust outputs are considered nonstandard, thus nodes won't accept the transaction and miners won't mine them.
|
|
|
|
Can the sender cancel the transaction by any means and resend it with a higher fee?
The sender could attempt an RBF transaction. Basically it is just the same transaction but it has a higher fee. The fee would need to be at least 0.0024138 BTC |
|
|
|
|
Once Bitcoin has been sent, it is not possible to reverse the transaction. What wallet were you using?
|
|
|
|
I just checked my account and it seems that it's quite behind. Posts: 8960
Activity: 980 (Hero Member) The missing 54 posts is probably because you are a staff member and can post in boards that normal users cannot see. The bot counts the posts directly instead of pulling them from the profile page. Aaah, I see. Yes that makes sense.  0.3528 BTC as an estimated price is a bit disappointing though. The bot give this price because it don't take in account your reputation, which he will never be able to. However, giving a small bonus of value for each positive trust point, and doing the inverse for the negative ones, would be a good idea I think. It does actually take into account the trust, just not very well. I will have to make that part of the algorithm better. It doesn't take into account his status as a staff member, which, if it did, it would estimate the price to be much higher. |
|
|
|
I just checked my account and it seems that it's quite behind. Posts: 8960
Activity: 980 (Hero Member) The missing 54 posts is probably because you are a staff member and can post in boards that normal users cannot see. The bot counts the posts directly instead of pulling them from the profile page. |
|
|
|
|
You need to post. You need to get 60 activity in order to become a member. To get 60 activity, you need to post at least 14 times every two week period since you can only get 14 activity per two week period. Please make your posts constructive and don't spam.
|
|
|
|
I am attempting to do this, but I keep getting stuck on building protobuf. It always ends with this error in a dialog box: The procedure entry point _ZSt24_throw_out_of_ragne_fmtOKcz could not be located in the dynamic link library c:\deps\protobuf-2.6.1\src\protoc.exe I am building this on Windows 10. |
|
|
|
No, 75% is not consensus and this has nothing to do with "my opinion". 90-95% (nobody ever talked about 100%) does not make sense only from a game theory perspective (most people here using this as an argument know nothing about it).
Well then enlighten us. If 75% is not consensus, then what is? And why? By definition consensus is 100%. However, in practice that is not achievable, so we use supermajority. The current definition of supermajority which is used by soft forks in the IsSuperMajority function is 95%, which is what we should use for hard forks. |
|
|
|
|
Show Posts
)
