 Show Posts
|
|
Pages: « 1 [2] 3 4 5 »
|
|
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.
|
|
|
|
Summarizing discussion from IRC: the problem is reproducible in that getwork is returning the same midpoint for ~14% of requests but slightly different data. [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
|
|
|
|
Cool!  |
|
|
|
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. |
|
|
|
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? |
|
|
|
|
You're not alone. The sexist trolling does get old after a while though:/
|
|
|
|
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=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.
|
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
|
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).
|
|
|
|
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. |
|
|
|
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. |
|
|
|
My vote: 2) Block statistics
|
|
|
|
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. |
|
|
|
|
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.
|
|
|
|
|
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?".
|
|
|
|
|
