Bitcoin Forum
September 28, 2016, 11:52:57 PM *
News: Latest stable version of Bitcoin Core: 0.13.0 (New!) [Torrent]. Make sure you verify it.
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 [25] 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 ... 228 »
481  Bitcoin / Development & Technical Discussion / Re: Transaction v3 (BIP 62) on: July 05, 2015, 09:48:41 PM
Means that if the version of the tx is different from 1 then the transaction is not standard.
So, at the end of the day, contrary to what BIP62 announce, there is no tx version 3 right ?
There is no BIP62 in the Bitcoin system today. It's an incomplete proposal; so there is no support for BIP62 at all.
482  Bitcoin / Bitcoin Discussion / Re: How bitcoin dev's are helping to kill bitcoin on: July 05, 2015, 09:47:10 PM
in other hand...you are still considering Bitcoin Core as Desktop application? Maybe something changed recently, but I still remember, that after each reboot was my 4 years old laptop ~30 minutes almost unusable, because core start syncing blocks from previous day and I didn't have SSD back in the time:)
Well you called out the reason there-- not having an SSD.  I run bitcoin core on a battery life optimized ultra light laptop and never notice it running.  That its a fine desktop application doesn't mean that it's super awesome on a 4 year old non-ssd enabled laptop. The much larger blocks these days do require more work to catch up on, but the software is also quite a bit faster.
483  Bitcoin / Development & Technical Discussion / Re: Numerically finding an optimal block size using decentralisation-utility on: July 05, 2015, 07:55:16 AM
Assuming a user will use all of their bandwidth is probably not good, You probably need to assign a marginal utlity to running a node and then scaling their tolerance based on their marginal utility and the available bandwidth.

I haven't personally chased this kind of approach because there will be so many judgements that the result won't really be interesting to anyone but the person who created it... but perhaps I'm wrong.

484  Bitcoin / Bitcoin Discussion / Re: How bitcoin dev's are helping to kill bitcoin on: July 05, 2015, 07:47:06 AM
dude, you should finally realize, that bitcoin core is not desktop application anymore. it consumes lot of disk space, bandwidth or cpu and you can simply avoid all this using electrum or multibit.
next time just educate yourself little bit before verbally attacking guys, which are obviously smarter than you..
This isn't fair or correct.

Bitcoin Core should work fine for Decksperiment, it shouldn't even mind his poor attitude.

But it's not-- even though it works fine for many many other people--, unfortunately Decksperiment has not provided enough useful information to begin troubleshooting, and his approach doesn't exactly encourage anyone competent to try to help.

If you're on windows and running the latest version, then I suggest running memtest86 and some disk check-- defective hardware is a common cause of issues. If you have antivirus software some of it is known to corrupt Bitcoin, you should disable it or except the Bitcoin directories.

485  Bitcoin / Development & Technical Discussion / Re: BIP 66 status on: July 04, 2015, 07:04:58 AM
Yes it's enforced now; at least by the potentially-minority parts of the miners that are actually enforcing any rules at all. Sad
486  Bitcoin / Bitcoin Discussion / Re: WARNING: blockchain split on: July 04, 2015, 06:43:34 AM
I'm using 0.10.2 and still got the message, it's not a version specific announcement.
The message was briefly up for 0.10.2 because 0.10 had failed to increment the protocol version and I failed to account for that. The there are two alerts which are active right now covering everything prior to 0.9 plus the specific subversion strings for 0.9.0-0.9.5.
487  Bitcoin / Bitcoin Discussion / Re: WARNING: blockchain split on: July 04, 2015, 05:44:39 AM
My concerns exactly and stated more elegantly than I could have. Perhaps there needs to be a change to the protocol to prevent this practice?
It's possible to do, prior proposals were dismissed as paranoia. I expect that even the evidence now won't be enough since this expirenced will be discounted as "sure, they were doing that before, but they won't do it again".

And now, you know why chinese pools thought they could survive with 8MB blocks.  Ultimately any proposal to inhibit SPV mining is going to interact in politically complex ways with the block size discussion. Sad
488  Bitcoin / Bitcoin Discussion / Re: WARNING: blockchain split on: July 04, 2015, 05:27:04 AM
from what?  all those 1 transaction (the 25btc) blocks?

nobody is going to get scammed with fake transactions, it's obv not intentional.. if it was, they'd be including a lot of their (own) transactions, instead they are including zero

also, re: blockchain has 'thousands of orphan blocks a day', huh?    more like 1 or 2 on average

ed: the only 'scamming' from transactions that could possible happen were with the original f'cked up block @ https://blockchain.info/block/0000000000000000009cc829aa25b40b2cd4eb83dd498c12ad0d26d90c439d99
There was about 4% of the hashrate remaining mining old invalid blocks; these SPV miners would extend them-- effectively boosting the invalid-block mining portion of the hashrate to 50% the moment one of those 4% miners produced an invalid block.

Miners that do not verify, even if they don't include transactions, are a huge amplifier on anyone who mines an invalid or malicious block for whatever reason; and are obviously a grave risk to the system.

More of these forks may still happen-- if these large hashrate miners leave the SPV mining code in place, there still is a few percent mining invalid blocks--- I know for the deployment of the P2SH softfork "50 BTC" continued mining invalid blocks for roughly a month.
489  Bitcoin / Development & Technical Discussion / Re: BIP 66 status on: July 04, 2015, 05:18:23 AM
So SPV and old full nodes will see 2 fake confirmations now.
SPV nodes made it up to 6 bogus confirmations.

There was basically half of the network hashrate extending an invalid chain. Sad
490  Bitcoin / Bitcoin Discussion / Re: Please list arguments against the idea of taking away Gavins' alert keys on: July 03, 2015, 07:36:29 AM
No he didn't.  Also gmaxwell is one of the core devs.  One of the people you trust implicitly (simply because they aren't Gavin), just told you there isn't a security risk.
To spare a little credit here; I'm unconcerned in part due to reasons that he was previously unaware of-- I think if I knew only what he knew, I would have been concerned. I'm thankful that people other than the development team are also thinking about these things and raising concerns; and I welcome it (though think it's much more productive if they're expressed in the most polite way possible; simply because adding emotion almost never makes a tricky situation easier)... it's just in this particular case I believe the concerns are adequately addressed for the moment, but I don't mind answering questions about it.
491  Bitcoin / Bitcoin Discussion / Re: Please list arguments against the idea of taking away Gavins' alert keys on: July 03, 2015, 05:19:03 AM
Thats a good info gmaxwell. I guess a fast reaction is almost certain then.
[...]
The results werent so impressing?
Yes, I estimate it could be corrected in under 5 minutes right now.

WRT result, the primary thing the alert does right now is triggers the error bar in Bitcoin Core and the alert notify output; which almost no one will notice. Past notices have had very little effect in general.

Basically, the person(s) with the alert key possesses the authority to instruct bitcoin users to update. So strangely, at the moment, a man that vanished 5 years ago has that authority as does a developer that has apparently broken away from core. Yet, to the best of my knowledge, no remaining core dev has this key.
More or less incorrect on both counts. Yes, someone can send a message-- but that message can be disabled, locked out, and replaced with a key compromised method by anyone with the alert key.  For security reasons everyone who has the alertkey is not enumerated (so that someone can't attempt to suppress use of the alert key by targeting multiple people). Multiple people currently active in the project have the key, and there are also other security measures in place.

I hear your concerns. You're not the first or only one to express them; but I believe there is still a more professional cooperative way forward available and I think we should make use of it to the greatest extent possible.
492  Other / Meta / Re: HashFast cypherdoc bankruptcy scandal : Time to clean up bitcoin on: July 03, 2015, 03:45:55 AM
Still, if it's more than marginally profitable, why sell those machines instead of mine with them?
Because of the huge risks and dis-economies of scale (supplying cooling and power at the multiple megawatt level is severely problematic; with installs wanting 20 year contracts and other such fun stuff).  But we're getting off-topic here.

Where does icebreaker fit in in all this?
I'm not sure if he's ever identified himself or been identified;  see https://bitcointalk.org/index.php?topic=381687.msg4133974#msg4133974

493  Other / Meta / Re: HashFast cypherdoc bankruptcy scandal : Time to clean up bitcoin on: July 03, 2015, 12:37:55 AM
2. HashFast
3. Cointerra
Cointerra actually shipped me hardware, it was a month late, under-performing and not super reliable--  it was still a MUCH better deal than Hashfast, which was just a pure money sink. I think the cointerra stuff delivered about as expected in risk return turns.

HF had much stronger promises, a full refund policy if they failed to ship-- claims of external investment to fund the operation instead of pre-order money, and a program to deliver hashrate if the miners didn't turn a profit.... and their claims were backed by community regulars who'd visited their facilities in person.  Turns out that they'd taken _massive_ payments, which themselves alone made it impossible for hashfast to deliver on their contract obligations (Can't give a full in-bitcoin refund when you've already given 10% of the Bitcoins away, not with Bitcoin prices rising).

The whole situation with crappy mining companies has done serious lasting harm to Bitcoin.  Small scale mining works _fine_, there are fundamental space/power advantages to not having large installs; and it's a fun real way to contribute to the system--- the real "economy of scale" in Bitcoin mining that actually exists is dealing with the fraud and fail laden ecosystem.   Sketchy companies have a severe commercial advantage because fantasy can always outperform reality.... and basically little incentive for parties to deliver on their word (or even close to their word) because there is basically no repercussion for breaking it.

It's going to take time, education, and effort to heal all the damage done to Bitcoin on the mining ecosystem side, but I think it can be healed...  but it's certainly a lot harder to foster integrity in the ecosystem when there remain no repercussions.  There is only so much we can do however-- prosecutions of "white collar crime" are thin; the perpetrators can throw up a smoke screen of plausible deniability and can afford to fight back.  I'm not just whining here because in this case I actually lost money-- I've made similar comments e.g. related to Zhou Tong even though I lost narry a cent there.  If we are talk about how disputes can be settled without constant (costly) recourse to state authorities (which are often helpless in the face of international disputes in any case), then we also have to live up to it; and at least take what measures we can within the community to protect each other through tools like reputation and social pressure.
494  Bitcoin / Bitcoin Discussion / Re: Please list arguments against the idea of taking away Gavins' alert keys on: July 02, 2015, 07:46:16 PM
We don't really use the alert mechanism, and many of the contributors to Bitcoin Core would like to remove it-- because the value it provides is very low, relative to the administrative overhead we receive in terms of people justifying non-starter proposals based on it (e.g. wanting to use it to remotely control miner default behaviour) or just the cost users have in reasoning about its security implications for them.

That said, there is very little potential for abuse, because if a bogus alert is sent a special alert can be sent that disables further use of the alert system erases all other alerts and sets a static alert key compromised message. As a result, active misuse is already effectively constructively disabled.

And all without fanning any extra drama.
495  Economy / Scam Accusations / Re: PSA: cypherdoc is a paid shill, liar and probably epic scammer: HashFast affair on: July 02, 2015, 06:07:24 PM
He's already screwed his reputation,
Dunno about that;  after the hashfast failed to deliver many people neg rated him--  and he made it out like he just got some discounted units from them that he lost money on, like the rest of the customers.  Given what he said before understating his involvement, and the fact that he'd claimed that he only benefited if it panned out-- it sounded completely believable. Many people who do equipment reviews, software development, etc. for mining don't get anything more than some free hardware and often just engineering samples.  I pulled back my negative rating, and others did as well; incorrectly sparing his reputation.

496  Economy / Scam Accusations / Re: PSA: cypherdoc is a paid shill, liar and probably epic scammer: HashFast affair on: July 02, 2015, 12:28:52 AM
After hashfast blew up (I lost ~100 BTC to it, got nothing in return-- bummer considering they'd promised early customers to return deposited coins if they failed to deliver), I negatively rated Cypherdoc on the forum -- after all, he pushed this stuff hard and if reputation is to mean anything at all your reputation ought to take a hit when you promote something that rips people off.   Cypherdoc then emailed me and convinced me that he was just another victim, that got discounts for some promotion-- sure-- but his orders failed too.  I took down the rating. People make mistakes, and being another hashfast victim would be punishment enough.

I was quite surprised to read the complaint-- to learn that he'd been paid an astronomic 3000 BTC for his "promotion" services in addition to discounted hardware that he was refunded for (while many other customers got nothing).  It's also more than a little perplexing-- as a developer of Bitcoin and a moderator of the mining subforum payments like that seem completely out of line with anything I've experienced-- some people get a single demo piece for review and such, or an engineering sample for driver developer but I can't fathom what would justify payments like that, and I can understand why he's being sued to recover them. Doubly so because in my experience while cypherdoc is a long time participant, he was not all that well known outside of certain niche areas of the community (his claim to fame is the "gold collapsing" thread he started), and he appeared to have no expertise in mining that wasn't held by thousands of other participants.

Though my opinions might be colored a bit by the fact that since that time he's been rather rude and aggressive towards me in public (I suppose he's the expert in financial conflicts of interest if nothing else, 'enh?)  ...  but I only restored my negative rating of him on the forum after discovering that his poor-me act was just an act, and that he was by no means just a victim here.  I think he should return the funds which were fraudulently taken from hashfast customers; and that his hundred some shilling posts should not entitle him to walk away with a massive profit while so many of hashfast's customers-- some who did buy specifically on his advice--  have received nothing in return for their payment.

If indeed there was some greater fraud afoot, the parties involved should still find it greatly in there interest to settle this matter as fast as possible before its details come to light in discovery.
497  Bitcoin / Development & Technical Discussion / Re: is FSS RBF really solving what it suppose to solve? on: June 29, 2015, 06:59:37 PM
The requirement is that it meets all the prior validity criteria (e.g. is locked) and that it is more preferred (plus some additional requirements on what its permitted to conflict with)-- at least thats the intent; you'll need to analyze the implementation, not a forum post, to determine if it accomplishes that.
498  Bitcoin / Bitcoin Discussion / Re: Pita Bread Munchers Could Steal Bitcoins from Public Laptops on: June 29, 2015, 01:13:53 PM
A core developer saying that should lay worries to rest. Though even though you say bitcoin is more secure against such potential attacks i wonder if one shouldnt be worried because they claim they perfected stealing pgp-keys. pgp should be really secure too, because of their use cases.
Ok, ill believe you on that anyway. Only wondering why PGP is vulnerable. Its a security software. And they sound pretty confident to being able hack private keys. Why would they when they dont see a chance or tested, before they release it to the press, that they work on it?
Maybe they mentioning bitcoin private keys is only a help for spreading the news.  Roll Eyes
Read the actual report, in particular http://www.tau.ac.il/~tromer/radioexp/  Q11 and Q8.
499  Bitcoin / Bitcoin Discussion / Re: Pita Bread Munchers Could Steal Bitcoins from Public Laptops on: June 29, 2015, 11:12:45 AM
Bitcoin Core uses signing which is constant time, constant memory access, and hardened in several other ways against side-channel private key leaks-- and specifically designed to resist these attacks. Actually being leak free also depends on the hardware, but at least in Bitcoin Core the software side of it is much more robust than the kinds of systems they were attacking here.
500  Bitcoin / Bitcoin Discussion / Re: New York Times identifies Nick Szabo as Satoshi Nakamoto on: June 29, 2015, 08:09:20 AM
Wait....
I am a little bit confused.
I thought Nick Szabo was a pseudonym...
You guys are now saying it's a real name?

Yes, that's what they're saying. They also have a photo above proving that Greg Maxwell is a former roadie for Crosby, Stills & Nash. It may be Maxwell in the rear left of this image but the face is cut off.



He got the roadie gig because he's the bastard child of Jerry Garcia (humor at the expense of Greg's mother).  Grin



You, who choose to lead, must follow
But if you fall you fall alone.
If you should stand then who's to guide you?
If I knew the way I would take you home.

I'm a bit young to have been a roadie for CSNY in the mid 70s, but heres the oldest picture of me I can find to aid in your diligent sleuthing:



(God knows, one of you will find a picture with me and John Perry Barlow and consider Glebs most crazy theories confirmed... and I can imagine little funnier than that.)
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 [25] 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 ... 228 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!