|
I agree with caveden: I think fees should be entirely up to the miners.
I like the idea of offering a small (฿0.0001) fee for every transaction, but wouldn't that just lead to more dust and wallet fragmentation?
Alternatively, we could greatly raise the limits for free transactions, or raise their score if they're old so they can get outside the free transaction space. What are the problems with that approach?
|
|
|
|
lachesis, can you make please a complete guide?
Sorry, I don't really have time for that. My hint would be to use a better AMI than the default, like the starcluster gpu one (ami-12b6477b), found here: http://mailman.mit.edu/pipermail/starcluster/2010-December/000572.html. However, I don't think it's worth it. First of all, there are only 2 GPUs as far as I can tell. Didn't see an option for a 4x GPU cluster. Furthermore, you'd need something like 1600 MHPS to justify the $2.10 cost / hour. |
|
|
|
|
Just tested this out today. I got about 77MHPS / Tesla core using an OpenCL miner, which is far too low to justify running the box. I didn't test with Puddingpop's CUDA miner, though.
|
|
|
|
|
My time is correct, and my debug.log shows nothing out of the ordinary. I'm stumped here, guys!
|
|
|
|
|
Yeah, I'm having similar results. I've been running a self-compiled Linux build on a machine with roughly the same khash and haven't generated a block since mid July. Of course, it was a _broken_ Linux build for a few weeks of that, but I'm running the latest SVN version now and still no luck.
|
|
|
|
I would like to simply be in a position to ignore this "document" provided by Jgarzik completely, but any future documentation written by any other member of the community that may be challenged as potentially a derivative of his document as he is the first person to put this information down in this fashion.
I challenge that assumption. I started documenting things like the version message before he released that. His documentation is broader than mine, but mine is more in depth. If you believe that the earliest description of the protocol in plain English somehow magically controls it, then we're safe since I came before him, and Satoshi probably has docs from 0.1.0 or before. In some ways, I'm tempted to simply say "damn the torpedoes" and copy the information in this document anyway.... challenging him to sue me for copyright infringement. It would be a precedent setting case in the very least on a whole bunch of levels and I have no certain idea how a court would end up ruling on the issue although I'm pretty confident that I would get the support of the greater Bitcoin community for standing up to this kind of behavior.
Honestly, I don't think Jgarzik's going to go to a court of law over a single page of docs, and even if he did, what would he accomplish? He couldn't stop Bitcoin nor could he co-opt the documentation. There are enough anarchist-type people in the Bitcoin community to be frightened of someone controlling the protocol or documentation or whatever by releasing an HTML table with a rough summary of messages as a copyright landmine of sorts. Let's not press this issue and drive away one of the few community members who is actually contributing code instead of just talking about it. |
|
|
|
I still have difficulties compiling from source. I look forward to that being intregrated into the binary client soon. Thanks. What platform are you on? I have builds for Linux on my site (out of date atm, but I can get a new release up soon). If you're on Windows, then I guess you're out of luck with me. |
|
|
|
Mainly, I have not given permission because it is woefully incomplete, I have some plans for that doc, and it was not only illegal but disrespectful to copy it without asking first. Still waiting for a simple acknowledgement that it was wrong, which would make me a lot more amenable to a creative commons license.
Some people have apologized: I apologize, jgarzik, if it appeared I had attempted or otherwise accomplished that of taking credit for your work. That wasn't my intention. I will add reference to your initial post as credit in the wiki post, if it hasn't been done so already.
That said, I agree that you have the right to prevent people from copying your works exactly if you so choose. You really can't stop them from using it to produce a derivative work, though - after all, how would you know they didn't just read the code themselves?
Some people in the community (NewLibertyStandard, I'm looking at you) are continuing to insist that you have no right to copyright your works, which is clearly false. That said, I don't think mizery meant any harm in posting your information on the wiki. You didn't originally specify anything suggesting that you didn't want the document copied. When you did specify that you didn't want your document posted, it was taken down. It is common practice in this forum to copy important or interesting information to our wiki. Thus far, nobody has cared. I vote his non-cooperative self-grandizing be rewarded by banning his contributions to svn and the forums. This way he can start his own fork with a license requiring each user to pray to him before launching the client.
Let's not overreact: this is a single page of documentation we're talking about. I could reproduce it in a few hours, but I really don't want to if it is eventually going to get released under a permissive license. Let's not alienate one of our best community programmers over a single page of documentation. Please guys, let's not make this a huge deal. Jgarzik, you could defuse this whole situation by releasing your document under a license that's friendly to copying and cooperation. NLS, please don't be a dick about all of this. Again guys, we're trying to build a community, not a conformity. If Jgarzik doesn't want to allow copying of his document, that's 100% his right. At least he has agreed to release all of his code, patches, etc etc with a MIT license, which is the really important part. Jgarzik, NLS, etc: I have great respect for all of you and your contributions to Bitcoin. Please, let's not make this a us vs him thing. |
|
|
|
... Of the nodes I'm connected to, more than half are already 0.3.10. ...
That's great news! How did you figure that out, though? I was considering writing a client specially tailored to put itself out there and try to get as many people to connect as possible, then survey their versions and write out a log (in addition to all the normal bitcoin stuff). |
|
|
|
Jgarzik's been doing a lot of good with his patches. I for one have incorporated his GetBlock and ListTransactions patches into my unofficial builds.
That said, I guess we do need to clarify the legal status of everything he's made now. Jgarzik, could you please publish a license or at least go on record with your feelings about copying and/or modifying your works? Do you require attribution?
If you don't, a lot of people (myself include) will naively (and possibly incorrectly) assume that you intend all of your code and documentation to be released under a permissive (MIT or BSD-style) license.
All of the code I've released is under the same license as bitcoin itself. Copy away, it's open source  I'm undecided about the documentation, but RHorning is way out there: it's ridiculous to think anyone will "take over" the protocol by writing a document and keeping it on their own website. As long as Satoshi distributes the code, he "owns" the network protocol, and I hope it stays that way! Thanks for the code. I think documentation should be released under some permissive open-source style license. That way others can correct potential mistakes, add info that you left off, etc etc and publish it back under the same license. Essentially, we should apply the FOSS philosophy to documentation. That said, I agree that you have the right to prevent people from copying your works exactly if you so choose. You really can't stop them from using it to produce a derivative work, though - after all, how would you know they didn't just read the code themselves? |
|
|
|
The "value out" in this block #74638 is quite strange:
That is strange. What does the TxIn look like? 92233720368.54277039 BTC? Is that UINT64_MAX, I wonder?
It's 2^63/10^8, so it looks like it's INT64_MAX, not UINT64_MAX |
|
|
|
Unfortunately we don't have an official changelog yet (except for the SVN revision descriptions).
...
Please tell me if you know of any other forum threads discussing the bugs/changes so I can add them to the list.
That's a great changelog. I sent you ฿2 for your trouble. |
|
|
|
|
Jgarzik's been doing a lot of good with his patches. I for one have incorporated his GetBlock and ListTransactions patches into my unofficial builds.
That said, I guess we do need to clarify the legal status of everything he's made now. Jgarzik, could you please publish a license or at least go on record with your feelings about copying and/or modifying your works? Do you require attribution?
If you don't, a lot of people (myself include) will naively (and possibly incorrectly) assume that you intend all of your code and documentation to be released under a permissive (MIT or BSD-style) license.
|
|
|
|
|
As to the solution, I've not seen a convincing reason that adjustments are done every 2016 blocks or whatever. Why not every 50 or 10? Yeah, difficulty would vary a lot more often, but how is that bad?
|
|
|
|
Added, as the "tx_time" field in listtransactions version 10.
Thank you |
|
|
|
Size of vectors and strings is stored using a compact size format: //
// Compact size
// size < 253 -- 1 byte
// size <= USHRT_MAX -- 3 bytes (253 + 2 bytes)
// size <= UINT_MAX -- 5 bytes (254 + 4 bytes)
// size > UINT_MAX -- 9 bytes (255 + 8 bytes)
//
The size field proceeds the vector or string of which it is specifying the length. Check out http://code.google.com/p/pybitcoin/wiki/BitcoinProtocol. We haven't gotten as far as you have, but we are making some progress on decoding the protocol. |
|
|
|
|
The problem with your analysis is that you assume that all for-profit minters will have the same profit margin. They won't. Among other things, larger minters will have economies of scale in their favour, making them more profitable.
In addition, as Bitcoin grows, people will develop dedicated hardware that maximizes the khash/dollar spent. In addition, people will tune the software in more and more precise ways to squeeze slightly more khash/second out of the same hardware. The people who invest a large fixed cost to do that will receive a correspondingly lower variable cost per Bitcoin minted in return, so they'll be able to mint at price levels that would drive others out.
Finally, at the point that this becomes an issue, everyone will be including transaction fees with their transactions to incentivize minting.
|
|
|
|
|
What's new? Do we have an official changelog yet?
|
|
|
|
|
Can you add the date and time associated with each transaction?
|
|
|
|
|
Show Posts
