Bitcoin Forum
August 29, 2016, 07:50:09 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 / 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.
482  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
483  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 @
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.
484  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
485  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.
486  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.
487  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

488  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.
489  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.
490  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.

491  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.
492  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.
493  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  Q11 and Q8.
494  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.
495  Bitcoin / Bitcoin Discussion / Re: New York Times identifies Nick Szabo as Satoshi Nakamoto on: June 29, 2015, 08:09:20 AM
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.)
496  Bitcoin / Development & Technical Discussion / Re: BIP 66 status on: June 29, 2015, 07:32:48 AM
I think there was a "hard fork" of the p2pool chain recently though to allow for a higher block version.
Orthogonal, there was an update which included a non-consensus change to pass through the higher version number that bitcoin core was already providing, as well as a non-consensus change to require Bitcoin core 0.10+, plus a non-consensus change to emit p2pool share v14, plus a p2pool-consensus change to enable requiring share v14, so that it's possible to fork off the participants who haven't upgraded once BIP66 has taken effect.  The latest p2pool block was v3.

Unfortunately, people thought that upgrading bitcoin was sufficient for p2pool to emit version 3 blocks, but unfortunately there was a min(template.version, 2) in the codebase; I didn't get around to checking until a couple days ago. Forrestv fixed it nearly instantly after I emailed him about it. Sadly, P2pool is hardly even a thing anymore... but the remaining users upgraded quickly and about 63% of P2Pool's hashrate updated in about two days, which I think is pretty good.

Minimum of 212 blocks until BIP66 enforcement right now (as of height 363020).

497  Economy / Speculation / Re: Gold collapsing. Bitcoin UP. on: June 28, 2015, 06:00:31 AM
There may be bug (or luck to find some number) and then creating bitcoins out of nothing. And nobody can verify.
That is the risk - the scheme relies on the security of ECDSA to protect the currency supply.
We're already relying on ECDSA to protect our balances from overt theft, so I'm not sure how much it actually changes the security model to also rely on it to protect our balances from covert theft via counterfeiting.
The reason I'm interested in amount blinding is that my current project is working out a multi-step plan to kill graph analysis. With the right plan and without blinded amounts we can kill graph analysis, but with blinded amounts we can drive a stake through its heart to make sure it stays dead.
We are also using SHA-256 and RIPEMD-160 hashes to protect our balances. So even ECDSA is broken our balances can be safe and then ECDSA replaced.
Pray tell how you will replace ECDSA when the coins are already assigned to keys for it?  (and when everyone and their sister constantly reuses addresses). A compromise of CT would mean that it was feasible to find discrete logs in this group, with that, anyone who learned your public key could recover your private key.  There are scenarios where the hashing, absent any address reuse, helps  (e.g. say the discrete log finding takes weeks)-- but it's important to not exaggerate the gains.

But indeed it isn't the ~quite~ same.

It's perfectly possible to construct schemes for private values which are unconditionally sound; meaning that there is no cryptographic assumption behind their inflation resistance, and a cryptographic break would only result in a loss of privacy.  I had previously thought that it was necessarily the case that any such scheme would have to be less efficient; but I have since realized my original reasoning for that was incorrect; though I do not (yet) know of a way to construct an unconditionally sound scheme which is anywhere near as efficient as CT;  but finding one is on my TODO list (though it falls below other improvements for CT privacy and network security that I'm working on).

498  Alternate cryptocurrencies / Speculation (Altcoins) / Re: [XMR] Monero Speculation on: June 28, 2015, 05:07:07 AM
I agree - any means to increase fungibility is a win. But based on my understanding of coinswap, this protocol would be human-centric? I.e., I'd have to arrange with some sentient thing (be it another human or a centralized service) to make it happen?
No, not at all-- it's just the norm to think about and describe protocols in terms of "people" making moves in a game.  All of this is automated and performed by computers.
499  Alternate cryptocurrencies / Speculation (Altcoins) / Re: [XMR] Monero Speculation on: June 28, 2015, 03:31:54 AM
(1) people who send BTC in the "ring signature sidechain" (RSSC), taint their BTC who are not entering the RSSC. If their identity is matched with the same identity as who put BTC in the RSSC, this person can become "flagged".
No, it's possible to trustlessly coinswap in and out of such a system, with no detectable connectivity.  And there are many reasons to use such a sidechain, such as improved smart contracting.  I consider improved fungiblity to be an essential basic feature.

Unfortunately, it's appears that it isn't possible to trustlessly swap in and out of monero because the developers of bytecoin didn't carry across smart contract functionality which they didn't understand.  Perhaps the capability could be added later.
500  Bitcoin / Pools / Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool on: June 27, 2015, 03:25:04 AM
Getting similar blank spaces occasionally, before and sometimes after the new work for worker message.

2015-06-26 23:20:00.404942 P2Pool: 17643 shares in chain (17647 verified/17647 total) Peers: 11 (0 incoming)
2015-06-26 23:20:00.405063  Local: 3221GH/s in last 10.0 minutes Local dead on arrival: ~0.9% (0-3%) Expected time to share: 2.4 hours
2015-06-26 23:20:00.405120  Shares: 0 (0 orphan, 0 dead) Stale rate: ??? Efficiency: ??? Current payout: (0.0172)=0.0172 BTC
2015-06-26 23:20:00.405177  Pool: 2345TH/s Stale rate: 14.3% Expected time to block: 1.1 days
2015-06-26 23:20:00.593721
2015-06-26 23:20:01.071310 New work for worker! Difficulty: 895.466842 Share difficulty: 6639421.564846 Total block value: 25.095099 BTC including 636 transactions

my logs have those from before, even days ago;  though not multiples.
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!