Bitcoin Forum
January 16, 2021, 11:16:07 AM *
News: Latest Bitcoin Core release: 0.20.1 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 [2] 3 4 5 »
21  Bitcoin / Pools / Re: [Bitcoins.lc] Issue with invalid shares (10 BTC bounty) on: June 10, 2011, 05:25:54 PM
I'm chasing a hunch. If anyone currently using bitcoins.lc would like to compare results from disabling Long Polling vs. leaving LP on, I'd find it instructive.
22  Bitcoin / Pools / Re: [Bitcoins.lc] Issue with invalid shares (10 BTC bounty) on: June 10, 2011, 12:22:15 PM
Summarizing discussion from IRC: the problem is reproducible in that getwork is returning the same midpoint for ~14% of requests but slightly different data.

Code:
[07:41] <lizthegrey> I'm seeing duplicate midstates
[07:42] <lizthegrey>       2 03dde4101cba6ba4d3a9d98bf6f074324b5ef4104e76257aa1f6e4374df10311
[07:42] <lizthegrey>       2 1b34e9976f563be464fbab7eb16bcae30aea5bc2428bb39cc168a1ea380fa4a0       2 203f9fc272d15f9a48b7f5c01252e14737302d104669a5a7ad40d5bf20065393
[07:42] <lizthegrey> (here's how I reproed)
[07:42] <lizthegrey> for i in `seq 0 99`; do (curl -d '{"method":"getwork","params":[],"id":1}' http://xxx:xxx@bitcoins.lc:8080/ > /tmp/state${i} &) ; done
[07:42] <lizthegrey> awk -F\" '{print($10)}' /tmp/state*|sort|uniq -c|sort|grep -v '^      1'
[08:10] <lizthegrey> here's one midstate/data
[08:10] <lizthegrey> "midstate":"befe8ff2573584e44cd82e1f818c7867d83c4d47104b9c504651945c4b9fb8fe","target":"ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000","data":"00000001458bbc3db0fdb6d264cfcd58bec77b06259835f18f8df83400000c680000000010ef5d24e007b8bf8e73d82cd2d62c2c87ed0f2dc404c7ecfa8ea1b83734d8754df2024e1a1d932f00000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000"
[08:10] <lizthegrey> here's another midstate/data with same midstate, different data
[08:10] <lizthegrey> "midstate":"befe8ff2573584e44cd82e1f818c7867d83c4d47104b9c504651945c4b9fb8fe","target":"ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000","data":"00000001458bbc3db0fdb6d264cfcd58bec77b06259835f18f8df83400000c680000000010ef5d24e007b8bf8e73d82cd2d62c2c87ed0f2dc404c7ecfa8ea1b83734d8754df202511a1d932f00000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000"
[08:10] <lizthegrey> notice df202511a1
[08:11] <lizthegrey> as opposed to df2024e1a1
23  Economy / Marketplace / Re: BDSM for Bitcoins (NYC) on: June 10, 2011, 11:03:27 AM
Cool! Smiley
24  Other / Politics & Society / Re: We've come to the point where we must protect our mining pools on: June 10, 2011, 12:49:21 AM
Already discussed over in Mining. http://forum.bitcoin.org/index.php?topic=9137.msg138150#msg138150
25  Bitcoin / Project Development / Re: Bitcoin Lawyer Introduction Thread on: June 09, 2011, 11:27:26 PM
For context, I'm in the UK, but I suspect the answer will apply regardless of the jurisdiction.

I'm of the understanding that if you buy BTC and then sell for profit at a later date, you're liable for Capital Gains Tax. But what's the tax situation if you're mining coins, and then selling them on your local exchange? My intuition is that it can't be CGT, because you didn't buy the coins in the first place - in the extreme case, you bought a mining rig, which was then used to produce coins, which you later sold. But I find it impossible to believe that you don't have to declare income gained like this. So what does it fall under?

This is a very good point that I hadn't considered. I'd imagine it would be the equivalent to how some CEOs take all or part of their salary as stock which they can then liquidate for cash. Never occurred to me whether that kind of liquidation would qualify as capital gains tax, income tax or some third kind of tax that I'm not aware of... I await a response!
I plan to declare the cost of electricity as an expense, and the bitcoins generated as profit; the net profit will go under self-employment (Schedule SE). I haven't bought any additional hardware, but if I did, I'd list it as a capital expense, take depreciation, etc.
26  Bitcoin / Development & Technical Discussion / Re: What would you change about the Bitcoin protocol? on: June 08, 2011, 10:20:39 PM
Well, if we are talking about a do-over, I'm pretty sure satoshi said something like "if I had to start from scratch, I'd use Google Protocol Buffers" and I agree with that.
Is there a reason a protocol buffers based protocol cannot be implemented as an additional RPC mechanism and the old mechanism phased out?
27  Bitcoin / Bitcoin Discussion / Re: How come there are no woman using Bitcoins? on: June 08, 2011, 04:01:09 PM
You're not alone. The sexist trolling does get old after a while though:/
28  Bitcoin / Project Development / [Proposal] Project code of conduct on: June 08, 2011, 03:12:05 PM
After having seen a fair amount of incivility on IRC and on the project forums, I feel that it would be appropriate for us to define as a community standards for behavior in order to make the community a more welcoming place for all people regardless of gender, race, ethnicity, national origin, disability, etc. Many other prominent open source projects such as Ubuntu, Fedora, Apache, OLPC have codes of conduct.

This is important in order to ensure that Bitcoin becomes mainstream and is used by a wide range of users and is accepting of contributions from developers that might otherwise feel harassed, threatened, or marginalized.

Modeled after https://launchpad.net/codeofconduct/1.1
Code:
=Bitcoin Code of Conduct v1.1=

This Code of Conduct covers our behaviour as members of the Bitcoin
Community, in any forum, mailing list, wiki, web site, IRC channel,
public meeting or private correspondence between community members.
Project developers, channel ops, and forum moderators will arbitrate in
any dispute over the conduct of a member of the community.

      '''Be considerate.''' Our work will be used by other people, and
      we in turn will depend on the work of others. Any decision we take
      will affect users and colleagues, and we should take those
      consequences into account when making decisions.  Bitcoin has
      hundreds of thousands of users and hundreds of contributors. Even
      if it's not obvious at the time, our contributions to Bitcoin will impact
      the work of others.  For example, changes to code, infrastructure,
      policy, documentation, and translations during a release may
      negatively impact others' work.

      '''Be respectful.''' The Bitcoin community and its members treat
      one another with respect. Everyone can make a valuable
      contribution to Bitcoin. We may not always agree, but disagreement
      is no excuse for poor behaviour and poor manners. We might all
      experience some frustration now and then, but we cannot allow that
      frustration to turn into a personal attack. It's important to
      remember that a community where people feel uncomfortable or
      threatened is not a productive one. We expect members of the
      Bitcoin community to be respectful when dealing with other
      contributors as well as with people outside the Bitcoin project and
      with users of Bitcoin.

      '''Be collaborative.''' Collaboration is central to Bitcoin and to
      the larger free software community.  This collaboration involves
      individuals working with others in teams within Bitcoin, teams
      working with each other within Bitcoin, and individuals and teams
      within Bitcoin working with other projects outside. This
      collaboration reduces redundancy, and improves the quality of our
      work. Internally and externally, we should always be open to
      collaboration. Wherever possible, we should work closely with
      upstream projects and others in the free software community to
      coordinate our technical, advocacy, documentation, and other work.
      Our work should be done transparently and we should involve as
      many interested parties as early as possible.  If we decide to
      take a different approach than others, we will let them know early,
      document our work and inform others regularly of our progress.

      '''When we disagree, we consult others.''' Disagreements, both
      social and technical, happen all the time and the Bitcoin
      community is no exception. It is important that we resolve
      disagreements and differing views constructively and with the help
      of the community and community processes. When our goals
      differ dramatically, we encourage the creation of alternative sets of
      packages, or derivative software so that the community can test
      new ideas and contribute to the discussion.

      '''When we are unsure, we ask for help.''' Nobody knows
      everything, and nobody is expected to be perfect in the Bitcoin
      community. Asking questions avoids many problems down the road,
      and so questions are encouraged. Those who are asked questions should
      be responsive and helpful. However, when asking a question, care must
      be taken to do so in an appropriate forum.

      '''Step down considerately.''' Members of every project come and
      go and Bitcoin is no different. When somebody leaves or disengages
      from the project, in whole or in part, we ask that they do so in a
      way that minimises disruption to the project. This means they
      should tell people they are leaving and take the proper steps to
      ensure that others can pick up where they left off.

We pride ourselves on building a productive, happy and agile community
that can welcome new ideas in a complex field, and foster collaboration
between groups with very different needs, interests and goals.
29  Bitcoin / Mining / Re: Think I just solved the pool problem. on: June 08, 2011, 02:23:54 PM
cuddlefish's solution requires running bitcoind on the miner side. What if miners who don't want to run it could opt to get work from trusted work streams?
Under my proposal, you are welcome to use someone else's local pool manager instead of your own. I'm imagining most people but not all will run a local pool manager, and only a small subset of people will run a DHT node, but there will be enough to keep the system resilient.
30  Bitcoin / Pools / Re: [80Gh/s+] Bitcoins.lc - Finally a usuable Bitcoin Pool! (EU, IPv6, 0% fee, LP) on: June 08, 2011, 12:12:32 PM
tested pool with 1 Ghash/s the last 12h. I had a very high rate of rejected shares (2%-5%).

I will come back when thats solved.

Besides that I like the pool!
^^
My stale share % with deepbit was 0.5%, but I'm willing to accept that bitcoins.lc is going to have a larger stale share % due to being in Europe rather than US where I'm located.
31  Bitcoin / Mining / Re: Think I just solved the pool problem. on: June 08, 2011, 11:31:00 AM
I'm confused, if shares aren't signed how do you collect?
You send your shares to several other peers who verify and commit to their distributed hash tables. When it's time to pay out, the distributor retrieves your shares from the DHT, verifies them, and generates the proportional share to give you.
32  Bitcoin / Mining / Re: Think I just solved the pool problem. on: June 08, 2011, 01:34:12 AM
I suppose what we need to do is change the entire system (everything) so that the pool can verify the generation address. Something like this.
{transaction data} -> {transaction hash}
{generation address}+{transaction hash}+{nonce} -> {final hash}
This way a pool member can send its own transaction hash once and the nonce of each share, but the pool still gets to verify the generation address. Is this the upshot of your proposition?
This change is very major and not in scope. What I am proposing to do is verify the entire block upon each share, but to have a distributed network rather than a single master verifying receipt of share.
33  Bitcoin / Pools / Re: [70Gh/s+] Bitcoins.lc - Finally a usuable Bitcoin Pool! (EU, IPv6, 0% fee, LP) on: June 07, 2011, 07:07:46 PM
Diablominer says i have ~240000khash/s, whereas in
 my statistics it shows hashrates from 95Mhash to 120Mhash.
Stats are averaged based on shares submitted over past 30 min. If you just joined, wait 30 min.
34  Bitcoin / Mining / Re: Deepbit Approaching 50% Once Again on: June 07, 2011, 03:56:12 PM
It does need to be pointed out that the magical threshold is not 50%+1. It is theoretically possible for an adversary corrupting 30% or 40% of the computation to eventually succeed trick the rest of the network into forking the block chain within several hours to days according to a study performed by a group of MIT students for the 6.857 Computer and Network Security class. I don't have their graphs/slides, but I can ask them for their data (and suspect they already haunt these forums).
35  Bitcoin / Mining / Re: Think I just solved the pool problem. on: June 07, 2011, 01:03:02 PM
Most of the entire block must be sent; otherwise, you could mine for yourself or for another pool and submit block hashes as 'proof of work' without actually working on solutions that pay the pool's payment address.

So, if I understand this right, and I'm not sure I do, the main problem is that there is no way to insure that the "generation address" is in fact the pool's address unless the pool hashes the block itself? So if the pool doesn't generate the hash for each block, you could potentially trick the pool into thinking that you are working on pool hashes when you aren't. When you actually hit a hash at the right difficulty, you claim it for yourself because you were actually using your address. At the same time you could submit the same work to a different pool that also can't confirm that you are using the correct address. Is this why you can't trust a pool member to provide the precomputed block data?
Correct.
36  Bitcoin / Mining / Re: Think I just solved the pool problem. on: June 07, 2011, 12:02:19 PM
Oh, ok I see now. I did not realize that the pool gave you partially precomputed data. Now it all makes much more sense. Could the pool member send the same sort of precomputed data back to the pool? This way the pool doesn't have to process every block itself? Then when a proper solution for the difficulty is found the pool could hash the entire block for verification. Is there some reason the pool would need to "pre-hash" every block from every user itself? Can the member not be trusted to send a valid precomputed value for the block?
Most of the entire block must be sent; otherwise, you could mine for yourself or for another pool and submit block hashes as 'proof of work' without actually working on solutions that pay the pool's payment address.

Edit: oh, I see, you could verify over time rather than all at once by just caching the values and computing later. Sure, that's a possibility, but this still doesn't address the 'single point of failure for recording work' problem that my proposal addresses.
37  Bitcoin / Pools / Re: Bitcoins.lc - Finally a usuable Bitcoin Pool! (IPv6, 0% fee, Long polling, JSON) on: June 07, 2011, 12:00:54 PM
My vote:
2) Block statistics
38  Bitcoin / Mining / Re: Think I just solved the pool problem. on: June 07, 2011, 11:18:40 AM
Current System (low bandwidth)

1. Pool gives block to you once
This is incorrect. The pool sends the partially completed hash, you never see the block you are working on. You only add the nonce and hash.

New system (lower bandwidth)
1. You generate your own block
2. Send block to pool once
3. Add nonce and hash
4. If share, send nonce to pool for verification
5. Repeat at 3, when valid block found start back at 1
This is much higher bandwidth, because the central pool master now has to process the entire block from each client every time the current block in progress changes instead of handing out precomputed data. This results in a DoS as all the clients supporting LP hit it at the exact same time with their new draft blocks.
39  Other / Politics & Society / Re: Are you going to pay taxes? on: June 06, 2011, 11:28:55 PM
I like my social services, thank you very much. Even though I disagree with the way my country spends 1/3 of its budget on flexing its military muscle, I have friends who work in public health, etc. who would lose their extremely-important-for-society jobs were enough people to stop paying taxes. And I do mean that non-sarcastically - preventing epidemics is damn important stuff.

I plan to deal with it as self-employment income rather than capital gains since I've been mining.
40  Bitcoin / Bitcoin Discussion / Re: Prediction: Universities will see a spike in their electric bills on: June 06, 2011, 09:05:11 PM
It needs to be pointed out that many universities have policies against using campus resources such as the network or the power for for-profit enterprises due to not wanting to endanger the university's not for profit status. That'll probably be the way such things are cracked down upon - "sure, you can mine all you want, but what good is mining if your network access is blocked?".
Pages: « 1 [2] 3 4 5 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!