Bitcoin Forum
May 30, 2024, 09:08:31 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 [146] 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 ... 288 »
2901  Bitcoin / Hardware / Re: Bitmain Antminer U2 on: March 06, 2014, 05:53:58 AM
Ive got a few boxes of these on hand.... pretty nice.
Of the U2s?  hows the software support? do they use the same software as the prior versions?
2902  Bitcoin / Development & Technical Discussion / Re: Increasing qt-wallet security to be protected by more than a single password on: March 06, 2014, 05:06:04 AM
Your illustration is very attractive, but it's still not clear to me what it's accomplishing.

If you are not using multisig how exactly is this two-phase transaction being completed? What specific technical mechanism prevents the desktop or the mobile device from unilaterally forming a transaction?

Contrary to your claim, multisignature would let you know an attempt was made and would allow you to reject it if it's not performing the requested actions.

Why do you not just send the transaction to the mobile device directly, since it is a necessary step in the process in any case? What purpose does the "precursor" network serve?

How do you protect this public network from being abused for bulk file transfer or other applications, especially since the data is encrypted?

Nitpick: The password protected QT wallet is itself two factors:  You must have the private keys on the computer (wallet file), as well as the decryption key. Adding the requirement for keying material stored/entered via the phone is a third factor— and a good idea. But this is what multisig was implemented for.
2903  Bitcoin / Development & Technical Discussion / Re: A rolling root to solve Bitcoin's scalability problem? on: March 06, 2014, 03:52:23 AM
Except your own Wiki says the opposite:
The wiki is a public document that anyone can edit. The scalability page is almost entirely the work of a single person who has removed views conflicting with his own onto other pages (including my own, for that matter).  You should be a sophisticated consumer of wiki content and not believe everything you read.
Quote
Quote
I think you should stop using the word trustless while you have multiple bitcoin developers telling you that you do not understand it.
The way my mind works is that I do not accept BS from anyone. It doesn't matter how large an angry mob gets if what it is saying is complete nonsense.
I've addressed every objection to this proposal, and have received confirmation on it now from two people who seem to know something about Bitcoin: Realpra, and a friend of mine whom I know is intelligent (works on SocialVPN).
You haven't really addressed _any_ of the objections here, because apparently you do not understand them. I spent quite a bit of time on IRC trying to help you understand but I have failed you. I'm sorry that I'm unable to help further.
2904  Bitcoin / Development & Technical Discussion / Re: A rolling root to solve Bitcoin's scalability problem? on: March 06, 2014, 03:36:32 AM
Quote
The fact is that ancient blocks, at any given point in time, are already highly trusted by the network. If they weren't, Bitcoin would simply not work.
There is already "trust" in the Bitcoin network, for these ancient block
Every node verifies the history, this is how you can be sure that claims like "satoshi premined a billion bitcoins and is secretly waiting to spend them" cannot be true. We do not trust, and cannot trust— because it would be trust founded on nothing. Without verification there is no reason for unidentifiable, anonymous parties not to lie in favor of their own common interests. What actually makes the Bitcoin state trust worthy is because people verify it instead of trusting it.

I think you should stop using the word trustless while you have multiple bitcoin developers telling you that you do not understand it.
2905  Other / Off-topic / Re: Need input from geeks. Is it possible to be traced in this way? on: March 06, 2014, 01:14:55 AM
Site doesn't work after the first load, I wonder if I just got spear phished.

In any case, assuming it's not a scam. If you want legal advice talk to a lawyer. If you want forum guesswork:  You have no clue what relationship this site has with the sources, they may have some bulk agreement. If there is copyright infringement, it's probably the sites infringement not yours.

Because academic authors and institutions are almost universally unpaid enforcement is complicated by the fact that the publishers are obviously parasites and don't make particularly charitable plaintiffs. If you're worried about someone harassing you for your use— use tor. Or find out what it takes to get papers access from a university library if one is available to you.
2906  Bitcoin / Hardware / Re: Why you shouldn't buy Hashfasts new "up to 800GH/s" "product" on: March 06, 2014, 01:04:30 AM
FWIW, Hashfast-cl has posted claiming that the only reason people are giving them negative trust is their scammy-looking self moderation.  I responded, pointing out that while their self-moderation is concerning, my negative trust is because they've ripped me off.  Sadly, they decided they didn't want people seeing that post either.

Quote from: Bitcoin Forum
A reply of yours, quoted below, was deleted by the starter of a self-moderated topic. There are no rules of self-moderation, so this deletion cannot be appealed. Do not continue posting in this topic if the topic-starter has requested that you leave.

You can create a new topic if you are unsatisfied with this one. If the topic-starter is scamming, post about it in Scam Accusations.

Quote
Using negative feedback to express dissatisfaction with a self-moderated thread is silly.  If you don't like self-moderated threads, simply don't read or post in them.
My dissatisfaction is not due to the self-moderation, and I believe I am not alone in that.

However, sometimes certain behavior with self-moderation may be a reason to distrust a party. If self-moderation is used to remove substantiated criticism that may be a severe red-flag.

In my case my negative feed back is that HashFast accepted almost 98 BTC from me for mining hardware to be delivered at the end of October under contractual terms— and assurances in direct communication with staff as well as public comments— guaranteeing a full refund if Hashfast failed to deliver by December 31st, a very generous timeframe considering delays that long would almost certainly guarantee that the equipment would be at a loss at that point.

HashFast, as is well known now, failed their initial delivery targets in October, and later they failed their drop dead date on Dec 31st. As of today, March 5, there are many people still expecting and waiting for hardware with no idea when it will be delivered. HashFast tried unilaterally changing contract terms— demanding customers agree to additional delays and an additional NDA and an agreement to not disparage the company if they wanted to receive any hardware or a refund— even though the customers had an existing established contract in which Hashfast was in default.

I paid HashFast and have received nothing in return. No response to my communications asking them to comply with their agreement or otherwise settle the matter. Beyond a single email that they relieved my first certified letter I have no evidence that they've actually read a single word I've sent them.  Other customers are already in the process of litigating against HashFast...  Personally, I just want them to make good on the agreement as they expressed it and I understood it.  I do not want to enter into an expensive and costly litigation which may ultimately leave hashfast out of business and unable to deliver the products to whatever few people are still purchasing with these substantial red flags at play.

To avoid any further confusion I've requested HashFast refund me in a publicly verifiable way: https://bitcointalk.org/index.php?topic=262052.msg5536343#msg5536343  so everyone has an easy check on much progress hashfast has made on making good on their agreements before placing further orders.

Until then, I'd continue to caution anyone against purchasing any products hashfast is offering.
2907  Bitcoin / Hardware / Re: Why you shouldn't buy Hashfasts new "up to 800GH/s" "product" on: March 05, 2014, 11:50:24 PM
An update:  Someone else mentioning this thread seems to have penetrated the reality distortion field which has prevented HF from acknowledging my existence— at least indirectly, and HF_CL commented on it.

I've responded inviting them to make good on their contract and refund me in a publicly verifiable manner:

https://bitcointalk.org/index.php?topic=262052.msg5536343#msg5536343
2908  Bitcoin / Hardware / Re: HashFast announces specs for new ASIC: 400GH/s on: March 05, 2014, 11:42:22 PM
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Quote from: HashFast_CL link=topic=262052.msg5514041#msg5514041
date=1393971437
HashFast sent gmaxwell a refund check in early January;
it was returned.  gmaxwell, if you want another refund check, please
let me know. 
Oh hey!  Wow!  I am astonished to see anyone
from hashfast acknowledge my existence after my many ignored letters!
Maybe things are looking up.

To avoid any further miscommunication, I'll just instead invite you to
refund me directly using Bitcoin. This way everyone can tell you made
good on your promises and there will be no risk of he-said-she-said or
certified letters getting lost on someone's desk or whatever has been
going on.

Please pay 97.95849881 BTC to 1MWwwz9gpViE3u7o6Sx6huYNBrHyze8QrA reversing
orders #934 and #1560 and ending HF's obligations to me.

This way everyone will see that you've made good on it, and I can
comfortably tell people that there were some delays and our transaction
didn't go through but that HashFast ultimately lived up to its promises to
me. ... and everyone can check if you've made that payment for themselves
without asking me if HF has fixed it yet.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJTF7X0AAoJEOq1r5TZ6avn+GMP/18yq7LZlz+umBFytz7CDSC2
CW5MRDil95jgHrwSSgSqwxrRxVbmEnVVeNjR65AaZOgS4rsro4wg/XFgoJUqxSL0
k5oieXta91YkOvGViOSPVfXhOiT8DlQFIv6ebhyIHqvd9Eb/GBBDRrPmATg93qoC
XBWp9ODV2IdqAmvRkcl49xTsBjouSkKA5I/tz6ykwDVtL5Z9QCaz80+5ZqPzRCB0
OHk105b3qv9iKLq8D5D0O1BxyHhGevAtKJsvffHf+sk7eJBcP89BQ0OK/fMn1T+O
M2hwpWjeZr4GxhRg4aaYwQfDYNm2WqlRhUNqZmYo817wpM4pdBU/Hy2RQ9mA23NC
mbdBj5fWigRCRVpAOWqKoGJxzh7i4nr3YYgNYqWHKG1za7pQB6lYI7m/X8dT+EPH
haVsC2AMYcJFVmqNwAf+rPoGOYz9SaJBxMM+Uw26emdvniaRC+3r6L1lF4AO52nn
MDEKoysZZ4IkrONyeyelyiuWUwZU/iIbH+BPghO2UOwnn5r+zoPSlnf0THAj57Bt
rxVYyFPD7/o35av9NvH1dOsd+UEqtw0rYUM/XTRFpc5SVXMmBo6lsZqS/AS0C9A+
O/N0S8BumO1hbYxgQROMwgUOxseen9zCfdpgP5JHEemneHd1lzFIYhJvs9QGkppF
eeOJh2I6CyRehCY4Oe13
=T/ss
-----END PGP SIGNATURE-----
2909  Bitcoin / Development & Technical Discussion / Re: Kimoto Gravity Well Difficulty Adjustment for Bitcoin on: March 05, 2014, 10:58:00 PM
I would be interested in knowing if anyone can think of any Disadvantages to using a moving average as opposed to a fixed 2 week readjust time ?
Using a moving average with a box filter halves the work an attacker needs to perform in an isolation attack to get the chain down to a level where they can simulate the running network.  It also requires you to move the clamping functions much closer in to keep them equally effective, which means they become easy to hit and it's not really easy to reason about the incentive implications of a non-linear difficulty adjustment (e.g. you potentially make it more profitable to mine in bursts).

This has been discussed many many many times before.

When you do not use the search function you risk having an uninformed discussion because the more expert people have gotten tired of rehashing the same subjects over and over again for years.
2910  Bitcoin / Development & Technical Discussion / Re: bitcoind sendfrom method - is it atomic? on: March 05, 2014, 09:22:36 PM
All updates to the wallet single thread through a common lock, so yes, it's atomic.

Though no one should be using the accounts functionality for this sort of thing, as there is no safe way to back up that data (among other issues).
2911  Bitcoin / Development & Technical Discussion / Re: Berkeley Database version 4.8 requirement unsustainable on: March 05, 2014, 07:35:21 PM
Changing to our own append only format has been the tentative plan for a long time.  BDB is not acceptable going forward for many reasons, and we've already eliminated it for non-wallet needs.  Breaking wallet compatibility is awkward though so no need to rush into it.

Your concerns about "unavailability" however are not interesting to me. The software is freely licensed, and we can just package and bundle it ourselves, and will likely have to as part of a wallet importing tool for the foreseeable future.
2912  Bitcoin / Development & Technical Discussion / Re: Distributed Transaction Signing on: March 05, 2014, 12:48:40 AM
The secret is in a separate bare-bones software which is watching the second blockchain, in the manner that Mike Hearn described a hypothetical piece of software watching Google.
Mike was describing a case where a system watching google is trusted to perform faithfully, or is a member of a collection of such identified semi-trusted systems where it is trusted that no more than some threshold will behave dishonestly.  This is normally what we're talking about when we talk about oracle mediated contracts.

Quote
Moreover, in the longer description I mention possible obfuscation techniques such as using the hash of a block as a source of randomness.
It is a hotly debated subject in theoretical cryptography if practically secure obfuscation is possible even in theory— even assuming many things which would make the effort insecure, impractical, or simply useless. It is not currently _practically_ possible in any case.

Quote
I hope you don't feel I'm wasting anyone's time. If you can explain how:
a) an Oracle can sign a transaction upon Mike Hearn winning a gold medal as reported by Google...
...is fundamentally and unalterably different from...
b) an oracle can scan a blockchain and sign transactions embedded within it after certain criteria are met
...then I'll close this specific request.
There isn't— but your question was unrelated to these points as far as I can tell.  There are actually secure ways to achieve the latter other than oracles, however, at least in theory (google coinwitness) but practice is another matter. (And, amusingly, not the former, because SSL doesn't provide non-repudiation)
2913  Bitcoin / Development & Technical Discussion / Re: Distributed Transaction Signing on: March 04, 2014, 11:58:12 PM
I actually asked Andy to respond to you and point you to his paper because your post concerned me and I thought the caution and historical context his writeup provided was highly applicable.

What you're asking its not generally possible in an anonymous system.  A signature proves the knowledge of a secret. In an anonymous distributed system there can be no secret. (Ignoring the question of effective program obfuscation being possible— which is hotly debated, and is not currently practical in any case, and even assuming it is, it is if this task can be accomplished without trusted initialization in any case).

If your system was not anonymous but had predefined membership then you could have a distributed secret— but there is no known way to do an ECDSA threshold signature directly. You could however use multisig in an enumerated entity (non-anonymous) distributed (but not decenteralized) system, and you can find a lot of information on that.  Alternatively, in a non-anonymous system multiparty computation could be used to use a shared key which is known to no one— but again not practical at this time, and not really any better than just multisig for this sort of application.

(And I provide this advice in some fear that you'll continue heedlessly to the cautions provided here— but I also want to make it clear that the response to you is fully in good faith, and trying to be helpful)

Generally the questions you're asking indicate to me that you haven't done that basic reading just to understand what things in cryptography are hard/easy and/or dangerous vs safe and that you have a lot of learning left to do that goes beyond the scope of the limited questions you're asking here.

I think oracle work is pretty interesting, but talking about things that would be highly cutting edge cryptography (if possible at all) ... isn't necessary for basic oracle work and should only be done with heavy research and caution.
2914  Bitcoin / Development & Technical Discussion / Re: Kimoto Gravity Well Difficulty Adjustment for Bitcoin on: March 04, 2014, 10:20:05 PM
Kimoto Gravity Well is an idea that has emerged and been refined as
pseudo-scientific gibberish by people who have no clue what they're talking about.

Please don't waste our time with things like this unless you understand it thoroughly yourself.
2915  Bitcoin / Hardware / Re: Why you shouldn't buy Hashfasts new "up to 800GH/s" "product" on: March 04, 2014, 12:35:10 AM
this should be set as a sticky..  or a buyers beware thread up top for all the bullshit scam companies
I feel like I can't reasonably do that because I can't vet every complaint with high confidence. And I don't want to just sticky vendors who have screwed _me_, while vendors who have screwed other people don't get the sticky.

And even when a company has screwed up some— been a bit late, a bit underspec, shipped a few bad units, or blown off a reasonable customer complaint— shit happens in business, especially one as time crunched for mining hardware.  Sell enough products and some are sure to break, have enough crazy customers and one is sure to try to operate it under-water and demand a refund. Where exactly should I draw the line?

So I think the simpler thing for me to do is to express my own opinion and experience as clearly and earnestly as possible, without pomp and distractions and encourage other people to do the same.


One idea I had was for the community here to operate a secret-shopper program— like a group buy, but which endeavors to covertly purchase one of every device its contributors thinks is sufficiently non-scammy and then reviews the device and rolls the returns into running the program (or paying back the people who sponsored it, if possible)... but the problem is that the results of such a test would come far too late to actually help people in most cases. Maybe a year from now the market will have settled some and doing some more "consumer reports" work will actually work.
2916  Bitcoin / Hardware / Re: Why you shouldn't buy Hashfasts new "up to 800GH/s" "product" on: March 03, 2014, 05:19:04 AM
So I'm just wondering, is gmaxwell going to start calling out all of the overpromising/underdelivering, cough BFL cough, hardware companies or just the one's he has money invested in and ignore the one's who have invested money in advertising here. Because there are/have been a lot of them out there and I haven't seen this kind of response until now.
I'm speaking from my own experience. Sadly, I can't really afford to buy a couple units from every vendor that comes along.  You'll note that I'm not using any special moderator powers here, e.g. kicking Hashfast's ass for deleting my post in their self moderated thread. I'm here as a (well known) community member.

(Y'all wanna fund me to buy one of every other piece of hardware, I will— and then I'll be glad to blast the everlasting crap out of them when they don't deliver... kinda costly though)

Quote
Regardless, this isn't all that surprising after my initial meetings with their team before they went public. Something was just off and then I found out they claimed that someone who is actually financially backing another company financed their operations. The dog and pony show was awesome, but when it came down to it, Lil Sebastian was/is late to the party still.
I was in Germany at the time of their announcement and couldn't do my normal due diligence which probably would have saved me— and did from several other vendors before. Sad

From now on I wouldn't agree to a preorder without using a multisig escrow or alike just to prevent the current situation.
2917  Bitcoin / Hardware / Re: Why you shouldn't buy Hashfasts new "up to 800GH/s" "product" on: March 03, 2014, 04:19:13 AM
I've heard from other people that they haven't spoken up on this because of HashFast's obscene NDA they added after Jan 1st for (some) customers to actually receive anything.  If you'd like to speak up and feel constrained by your agreement, please contact me. I may be able to help.

I'm currently looking for whomever owns hashfastscam.org (or similar domains) and I'm also interested in getting in contact with other hashfast customers in the SF bay area.

And if you are thinking of buying their new product after seeing the above, I think a lot of people here would be very interested in hearing why.
2918  Bitcoin / Hardware / Why you shouldn't buy Hashfasts new "up to 800GH/s" "product" on: March 03, 2014, 03:38:30 AM
I posted this in the thread Hashfast has created promoting their "Yoli Evo Mining Board up to 800GH/s", advising you that in my expirence if you pay hashfast your funds will just vanish into a black hole of non-delivery and no communication.

Unfortunately, for some reason Hashfast does not want you to see this vital information about the integrity of their operations and the realities of their product non-delivery— so they deleted my post.  I think this is critical information for anyone considering doing business with Hashfast— and especially anyone considering buying in to another pre-order of theirs, so I've created a new thread for it. I can see no reason why these concerns wouldn't be equally applicable to their latest vaporware.

Quote
Just in case people are forgetting.

Hashfast is a bunch of thieves. I do not say this lightly: They have literally taken my coin, violated their contract, and provided me with nothing in return. I paid them 98 BTC for hardware "scheduled" to be delivered in October. It's March 2nd now have received _nothing_ and they have not responded to any of my past private efforts to resolve the matter— now spanning months.  (Copies of communications and certified letter tracking numbers available on request).

I am not some competitor or troll: I'm a moderator of this sub-forum and a developer of the Bitcoin reference software.  I have no financial interest or otherwise in any other mining hardware company. I mine personally to support the Bitcoin network.  I've made a genuine effort to resolve this matter from hashfast, but it seems instead that they plan on taking my funds and running.  I sometimes feel bad that I probably do get "more fair" treatment than others with a lower profile in the community, but if they're willing to do this to me then what are they willing to do to you?

Business screwups and delays happen, but in my opinion Hashfast has gone far beyond those boundaries and into the space of outright theft.  Every additional sale hashfast makes while screwing over me and other miners in this manner damages the Bitcoin ecosystem and discourages me— and presumably other small miners— from participating. I've taken what I feel to be a fairly soft hand in this so far, in the hopes that they'd make things right after they cleared up some of their startup hurdles— but with new products being promoted, it seems that isn't their plan.

I urge everyone to provide HashFast with no further business until they make right by their past customers.

If you're looking for hardware and haven't been (rightfully) scared off by the astronomic prices being charged by current hardware vendors— I can personally vouch for Bitmain's Antminer S1s (*), which are delivered promptly, with absolutely no pre-order nonsense, and perform precisely as specified. Cointerra products also appear to be competently handled (though current units only deliver ~1.6TH/s against their original 2TH/s spec, and at least my unit has some hashrate stability problems when run at full speed), and they've treated their customers with reasonable respect (e.g. compensating customers for delays above and beyond the contract).


(*) Disclosure, fwiw: Last year Bitmain sent me a prototype 90GH/s antminer for testing/development prior to their public shipping. I subsequently bought a couple others as a normal customer and have been pretty happy with them as have virtually all of their other customers. Rather than seeing this as a source of potential bias here I'd point out that any well run mining hardware company would get pre-production units out to developers in order to avoid the early product missteps that other companies like HashFast have had.
2919  Bitcoin / Development & Technical Discussion / Re: CoinJoin: Bitcoin privacy for the real world on: March 03, 2014, 01:46:22 AM
The extant solution for anonymous networks (Tor) requires extra steps that many users won't do,
Tor is actually quite easy to bundle, and some other programs (like torchat) already do. I'd assume that someday there would be bitcoin clients offered with bundled tor.
2920  Economy / Service Discussion / Re: Post Your Mt.Gox Call Center Convo Here on: March 03, 2014, 01:35:47 AM
I got five minutes of elevator music and then I bailed out. Didn't want to wait on hold for a half an hour to perhaps get someone who only speaks Japanese— I figure I'll try again once someone reports how it goes, potentially bringing in a translator if required.
Pages: « 1 ... 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 [146] 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 ... 288 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!