I agree it's too late to change BTC or probably any of the other units. But if the whole unit system were to be reorganized, something like this would be much more sensible. |
|
|
|
Would the rest of the community still accept the blocks generated with this lower fee? Yes. Currently I cannot send anything less than ($1) 0.149BTC without the client adding a 0.01-0.02 BTC (7%) transaction fee. That's the fault of your client. So long as you send at least 0.00000016 BTC, your fee only needs to be 0.00004096 BTC (assuming a fairly normal transaction size) to be accepted by Eligius (which should easily be within 24 hours). |
|
|
|
|
This could create strategic problems for pool operators. With the current "plan", it is impossible for the often-foreseen future where merchants can pay a flat monthly "priority fee" to pools and such. So any system which allows the end-miner to control block creation would probably need some kind of way for the pool to say "must include txids <x>, <y>, <z>" as well...
|
|
|
|
When I talked to Gavin, he gave me the impression that people just go ahead and do things without permission from any leaders. If people want this, it may survive. If not, we just do other things instead and I've only wasted a little time trying out an idea. I'm okay with that. I for one don't recognize a distributed project like Bitcoin as having any leaders per se, so I agree in that respect, but with respect to starting a standards organization, "just go ahead and do" it would to me mean talking to other people who are already involved in the area (which I was assuming before was technical) and getting a group of people to form it together. |
|
|
|
|
I agree that a standards organization could be a good idea (better coordination to create the new wallet protocol spec, for example)...
But, you seem to be founding this as a newbie (only been involved in the Bitcoin community for a month?) with no prior consulting with existing community members who have already created the current de facto standards (JSON-RPC, the p2p protocol, etc) or have put effort into development of newer standards (like the wallet protocol). Furthermore, you have started this group having already made decisions for it by yourself ("Upcoming open standards" has five "standards" that have no documentation nor prior discussion as far as I know).
That being said, I'll "join" just in case this works out to be a beneficial effort.
|
|
|
|
Restarted the US server... apparently my watchdog didn't trigger last night  I might need to setup a testnet pool to do some pushpool debugging or something 1MX12iNFncGnuxja4xpwSF66Zx6xcA5hmY is getting a lot of work-not-in-log. Could you try regular poclbm from git and let me know if that has better results? Perhaps also try eu.mining.eligius.st? |
|
|
|
There's already Eligius  |
|
|
|
|
Couldn't find an existing thread for this... but IMO, if people start expiring transactions, those found in orphaned blocks should be exempt. Possibly even given infinite priority and bypass any ordinary block-acceptance rules too.
|
|
|
|
I'm getting a lot of stale shares. Is this normal for Eligius? Are rejected blocks bad? This suggests a problem on your miner. What address? |
|
|
|
Just what is non-standard about non-standard transactions? bitcoind and the wx client will boycott them, and refuse to include them in blocks or even relay them. What's the difference between non-standard and invalid? Invalid breaks the network rules in some way. "Non-standard" are just not liked by the developer team of the client with the biggest marketshare. Can arbitrary data be stuffed into a transaction? If not, what are the limitations? Yes, both standard and non-standard. But don't do that, please. Need these be "transactions" at all in the sense of involving transfers between bitcoin addresses? They have to be transactions, but don't have to involve addresses. How do I go about creating a non-standard transaction? Hack away at one of the clients (even an extremely light partial-client is probably enough). Make sure you include enough of a fee to get it into a block. What are some (actual or potential) use cases? - Require KeyA and KeyB (eg, escrow agent) to spend the coin
- Require KeyA or KeyB (eg, State garnishment super-key mandated by law on citizens) to spend the coin
- Allow anyone to spend the coin without any key
- Require a password in addition to a key
|
|
|
|
|
Bump. I just realize a reason this is immensely useful (besides Eligius): no longer do transactions require unique destination addresses. A merchant can publish a single address/email pair for all purchases, and clients can send the purchase information via email, signed by the sending address.
|
|
|
|
I'll do it for 200.
100 if the resulting app is open-sourced.
Isn't there already an open source Point-of-sale system that could be modifiyed to handle bitcoin payments? I know that there is a POS system based off of the Ipad that already intergrates Bitcoin, but to what degree that is so, I know not. And they are not open source. That seems implied in the price. 100 BTC is only like 2-3 full days of coding time. |
|
|
|
That's neat. Would be cool to show it on the main site... maybe a script to append it to bitcoin: URI text? Been thinking about how I could best facilitate so people can put a snippet on their pages. Is that what you mean? I think I don't quite understand "a script to append it to bitcoin: URI text". Well, the webpages will have <a href="bitcoin:someaddress">someaddress or other text</a>, and a script could find those elements and append " ( n BTC so far)" or similar to the text of the link. Or maybe it's better to configure it per-link and have a class="showbalance" |
|
|
|
That's neat. Would be cool to show it on the main site... maybe a script to append it to bitcoin: URI text? |
|
|
|
Not sure, waiting on a response to a PM to work out the details. I think I just need to pay the ~$7 or so to clear Luke's name. Please don't feed the troll. It's pretty clear that nobody buys his nonsensical claims. |
|
|
|
although ithought that you had combined the EU and US servers so when they found a block, i would presume we get paid too? They are still separate, and probably will be for a while. Combining them is not trivial due to the immediate payout stuff. ALso, is there a current way of finding out just how much the server thinks me alone is hashing (should be in the 1 gh/s range) http://eligius.st/~luke-jr/hashrate.php?addr=15sE1b7Y6rLMBwwyBLGwSBTQzvB8csUfrX |
|
|
|
Now that is VERY interesting, it is stating on the page you have made we found a block today, yet my balance still hasnt been transfered across, now the balance is at 7.5BTC I cannot do any research without an address to look up... There is currently about 10 BTC delayed today, due to a lot of the sub-1-BTC-per-day-earners reaching their minimum and being paid out. how to move to EU server? stop miner and start again? change domain to eu.mining.eligius.st |
|
|
|
Can my balance be transferred to a different address? It's only 0.01 BTC but times are hard... If you can prove you own the original address, I can possibly transfer the balance. To date, proving this is extremely difficult. I suggest anyone with such a balance leave it under 0.16 BTC (which I am considering moving the minimum payout to) until signmessage is standardized. @Luke: Would it be possible to automatically move miners to a pool that is best for them? So you always connect your miner to the "main server" but it then actually calls the closest one (similar to Google's 8.8.8.8 DNS). DNS is stateless UDP, so it can use IP anycast. Mining is stateful TCP, so the same concept does not apply. My affiliate has some kind of GeoDNS that can resolve a domain based on lookup origin, which may work. He is pretty busy right now though, so it might be a while. Expect "mining.eligius.st" to resolve to a geographically-ideal server when he gets the time for this. Are transaction fees mined handed out as well? No, as state in the first post, the pool retains all transaction fees. Technically speaking, it will use them for payouts, but it simply does not include them in calculating balances. Any special anti-cheating voodoo concerning shares (devaluation of earlier shares for example) or just simple: own shares/all shares = payout? Simple own shares/all shares. I consider devaluation of earlier shares to in fact be the real "cheating". There is no evidence that someone should be paid any less simply because their work was earlier, or paid more because their work was later. |
|
|
|
This will avoid your password to be stored in history files If you dont want something in .bash_history (probably works for others too) you can just prefix the command with a space. Doesn't mean the point isn't valid but still... It will still show up on the process list ('ps aux') at least for some duration. I would be concerned with the timeout mechanism creating a race condition. A virus/trojan is going to be able to spend the coins faster than the user. But I guess it could just be added to the already-long list of JSON-RPC problems to be addressed by any contending protocol. |
|
|
|
|
Show Posts
