|
The current code is very inefficient at generating work, so on long rounds it can take a number of seconds to return new work. I'm currently working on a new version to optimize it.
|
|
|
|
and as to the vulnerabilities, it allows any malicious software to open ports in your firewall whether you want them or not once its on your computer. This "vulnerability" assumes that UPnP meant to configure firewalls, which it isn't. It's to inform a NAPT device of a port being opened. It really should be implemented by the OS's listen() function. |
|
|
|
what about your patch for the forum, that without slashes?
it's compatible, so will it be implemented any time soon? theymos wanted someone to test it before applying it. |
|
|
|
Ah, I see. Normal people call it "hexadecimal" and I've never heard of "hexadecimal users". Who are these people? Old school programmers, who can't go to the supermarket, because all numbers there are plain decimal? Hexadecimal is a newer, incomplete number system. Probably everyone who knows Tonal can use Decimal, but prefers Tonal because it is a sensible number system and thus easier to work with. And why Vladimir's scheme is "too easy" for them? It uses normal decimal numbers as I understand. Should we make it harder for them weird folks somehow? Some people object to the standard URIs because it is "too easy" for tonal users. I agree that people shouldn't go out of their way to make things harder for "weird folks". But there has been no other argument made against the standard URIs as of yet. |
|
|
|
Just out of curiosity - what the heck are "tonal users"  People who prefer the Tonal number system rather than Decimal/SI. |
|
|
|
Just preserving the above to demonstrate that all this argument was actually about this tonal thing (whatever it is) or absence of it after all. That it's "too easy for tonal users" is the only "argument" that's been put forward against the current spec. If you're trying to argue on some other premise, maybe you should state it instead of simply promoting an older pre-standard draft without giving any reasons. |
|
|
|
A bigot is a person obstinately or intolerantly devoted to his or her own opinions and prejudices, especially one exhibiting intolerance, and animosity toward those of differing beliefs. If anyone demonstrates bigotry here it is you, Luke-Jr. The above definition exactly describes you behaviour and position, not only ITT but in many other discussions as well. If there was an ignore function on this forum I would use it on you right now. Goodbye. Um, no. Why don't you read the definition you posted? The only objection to the bitcoin: URI spec has been that it's supposedly too easy for tonal users. There is nothing in it to force or even encourage people to use tonal. I don't mind if people use decimal (though I do consider it a dumb decision), only when people try to force me to use it as well, which is the case here. |
|
|
|
btc://amount:payee@address/message
Now, for the life of me, I fail to see how is this non compliant with relevant RFC. You would have to claim that commonly used http: URI's are non compliant as well to support 'non compliance' argument. How can you not see how this is non-compliant? Amounts are not usernames; "payees" (whatever those are) are not passwords. Neither addresses nor messages are in any way hierarchial. It also does not make any improvement on the existing URI scheme. Not to mention it isn't backward compatible. Here is a fledging developer who thinks that existent URI scheme is crap (so do I) and whether he is right or wrong lets encourage his effort to implement an alternative. The current standard is basically ideal for payments. The only "arguments" that have come up (all fairly recent) are based on bigotry and (to a limited extent) the flawed assumption that everyone will always want to use BTC for pricing (proven recently by many efforts to come up with a new common unit, which the bitcoin: URI scheme spec handles gracefully). |
|
|
|
@ Luke-Jr, There never was consensus reached on that. It is not a standard, just a page on wiki. Please do not call, whatever you like, a standard, it is not. If I am wrong here please explain why. There was a consensus reached at the time, and implementation proceeded to take place over the few months following. It is now supported by most Bitcoin-related software where it makes sense, and has been for some months at least. I have one practical suggestion. Lets have more than one URI scheme.
We have a well documented bitcoin: scheme RFC on wiki, great!. Let's prepare competing btc: scheme suggestion along the lines of what myself and AlexZ are advocating, let's also have bit-x: scheme (why not?). Your proposal was, in reality, an early pre-draft version of what became the standard on the "URI Scheme" wiki page. After the community revised it to comply with the generic URI standards, that wiki page was the end result. X-btc aims to specify a URI scheme that is applicable for more than just payments (which is all the bitcoin: URI scheme covers presently). It also has (had?) some generic-URI-format compliance issues that might be good to work out. |
|
|
|
Here's a patch to add compliant support for bitcoin: URIs. It probably should cleanup/strip any extra //, but I'll leave that to someone else to figure out. It also tries to detect standalone bitcoin addresses and turn them into links. I haven't tested it at all, so use at your own risk. Donations for this patch to 1HXo9py5hFsa528ZuXnSPHcXMyKiB7GN5U diff -ur smf_1-1-13_install/Sources/Subs-Post.php smf_1-1-13_install.bitcoin/Sources/Subs-Post.php
--- smf_1-1-13_install/Sources/Subs-Post.php 2011-02-07 11:45:09.000000000 -0500
+++ smf_1-1-13_install.bitcoin/Sources/Subs-Post.php 2011-06-11 12:29:56.169981884 -0400
@@ -330,28 +330,28 @@
// [url]http://...[/url]
array(
'tag' => 'url',
- 'protocols' => array('http', 'https'),
+ 'protocols' => array('http', 'https', 'bitcoin:'),
'embeddedUrl' => true,
'hasEqualSign' => false,
),
// [url=http://...]name[/url]
array(
'tag' => 'url',
- 'protocols' => array('http', 'https'),
+ 'protocols' => array('http', 'https', 'bitcoin:'),
'embeddedUrl' => true,
'hasEqualSign' => true,
),
// [iurl]http://...[/iurl]
array(
'tag' => 'iurl',
- 'protocols' => array('http', 'https'),
+ 'protocols' => array('http', 'https', 'bitcoin:'),
'embeddedUrl' => true,
'hasEqualSign' => false,
),
// [iurl=http://...]name[/iurl]
array(
'tag' => 'iurl',
- 'protocols' => array('http', 'https'),
+ 'protocols' => array('http', 'https', 'bitcoin:'),
'embeddedUrl' => true,
'hasEqualSign' => true,
),
@@ -475,7 +475,10 @@
$found = false;
foreach ($protocols as $protocol)
{
+ if (strpos($protocol, ':') === false)
$found = strncasecmp($replace, $protocol . '://', strlen($protocol) + 3) === 0;
+ else
+ $found = strncasecmp($replace, $protocol, strlen($protocol)) === 0;
if ($found)
break;
}
diff -ur smf_1-1-13_install/Sources/Subs.php smf_1-1-13_install.bitcoin/Sources/Subs.php
--- smf_1-1-13_install/Sources/Subs.php 2011-02-07 11:45:09.000000000 -0500
+++ smf_1-1-13_install.bitcoin/Sources/Subs.php 2011-06-11 12:53:18.829672859 -0400
@@ -1330,7 +1330,7 @@
'content' => '<a href="$1">$1</a>',
'validate' => create_function('&$tag, &$data, $disabled', '
$data = strtr($data, array(\'<br />\' => \'\'));
- if (strpos($data, \'http://\') !== 0 && strpos($data, \'https://\') !== 0)
+ if (strpos($data, \'http://\') !== 0 && strpos($data, \'https://\') !== 0 && strpos($data, \'bitcoin:\') !== 0)
$data = \'http://\' . $data;
'),
),
@@ -1342,7 +1342,7 @@
'validate' => create_function('&$tag, &$data, $disabled', '
if (substr($data, 0, 1) == \'#\')
$data = \'#post_\' . substr($data, 1);
- elseif (strpos($data, \'http://\') !== 0 && strpos($data, \'https://\') !== 0)
+ elseif (strpos($data, \'http://\') !== 0 && strpos($data, \'https://\') !== 0 && strpos($data, \'bitcoin:\') !== 0)
$data = \'http://\' . $data;
'),
'disallow_children' => array('email', 'ftp', 'url', 'iurl'),
@@ -1599,7 +1599,7 @@
'content' => '<a href="$1" target="_blank">$1</a>',
'validate' => create_function('&$tag, &$data, $disabled', '
$data = strtr($data, array(\'<br />\' => \'\'));
- if (strpos($data, \'http://\') !== 0 && strpos($data, \'https://\') !== 0)
+ if (strpos($data, \'http://\') !== 0 && strpos($data, \'https://\') !== 0 && strpos($data, \'bitcoin:\') !== 0)
$data = \'http://\' . $data;
'),
),
@@ -1609,7 +1609,7 @@
'before' => '<a href="$1" target="_blank">',
'after' => '</a>',
'validate' => create_function('&$tag, &$data, $disabled', '
- if (strpos($data, \'http://\') !== 0 && strpos($data, \'https://\') !== 0)
+ if (strpos($data, \'http://\') !== 0 && strpos($data, \'https://\') !== 0 && strpos($data, \'bitcoin:\') !== 0)
$data = \'http://\' . $data;
'),
'disallow_children' => array('email', 'ftp', 'url', 'iurl'),
@@ -1747,7 +1747,7 @@
// Take care of some HTML!
if (!empty($modSettings['enablePostHTML']) && strpos($data, '<') !== false)
{
- $data = preg_replace('~<a\s+href=((?:")?)((?:https?://|ftps?://|mailto:)\S+?)\\1>~i', '[url=$2]', $data);
+ $data = preg_replace('~<a\s+href=((?:")?)((?:https?://|ftps?://|mailto:|bitcoin:)\S+?)\\1>~i', '[url=$2]', $data);
$data = preg_replace('~</a>~i', '[/url]', $data);
// <br /> should be empty.
@@ -1836,10 +1836,14 @@
// Only do this if the preg survives.
if (is_string($result = preg_replace(array(
'~(?<=[\s>\.(;\'"]|^)((?:http|https|ftp|ftps)://[\w\-_%@:|]+(?:\.[\w\-_%]+)*(?::\d+)?(?:/[\w\-_\~%\.@,\?&;=#(){}+:\'\\\\]*)*[/\w\-_\~%@\?;=#}\\\\])~i',
- '~(?<=[\s>(\'<]|^)(www(?:\.[\w\-_]+)+(?::\d+)?(?:/[\w\-_\~%\.@,\?&;=#(){}+:\'\\\\]*)*[/\w\-_\~%@\?;=#}\\\\])~i'
+ '~(?<=[\s>(\'<]|^)(www(?:\.[\w\-_]+)+(?::\d+)?(?:/[\w\-_\~%\.@,\?&;=#(){}+:\'\\\\]*)*[/\w\-_\~%@\?;=#}\\\\])~i',
+ '~bitcoin:(\w+(?:\?\S+)?)~i',
+ '~\b([1-9A-HJ-NP-Za-km-z]{26,35})\b'
), array(
'[url]$1[/url]',
- '[url=http://$1]$1[/url]'
+ '[url=http://$1]$1[/url]',
+ '[url]$1[/url]',
+ '[url=bitcoin:$1]$1[/url]',
), $data)))
$data = $result;
|
|
|
|
|
I said it before: Vladimir's thing is not a compliant URI.
|
|
|
|
|
The password is not accessible without hacking pushpoold, and has obvious security issues. Using it is out of the question. Any kind of per-user configuration can wait for signmessage.
|
|
|
|
Why can't they just put in a setting where you can show it however you want?
They don't want people to use Bitcoins any way other than the one they approve of. Spesmilo supports displaying things in various ways. |
|
|
|
Would be cool to have a version number on these builds, I suspect them to be still a beta version. Anyone is welcome to upload their own builds if they want to make a different version  |
|
|
|
The current method avoids more transaction fees. Fees are incurred based on the difference from what you received to how much you're sending. If most of your sends are 0.5 BTC to 5 BTC, 1 BTC is ideal. But if most are 0.01 BTC to 0.5 BTC, 0.16 BTC payouts make more sense. While combining tiny coins incurs fees, so does spending young coins-- and you keep getting young change by splitting a big coin. [Edit: As far as I understood it, as long as coins are generated at the same address, it shoudn't matter if they are 100* 1 Bitcent or 1*1 Bitcoin --> but if you switch accounts after each payout (for whatever reason?!) this might be a viable concern.] This is incorrect. The Bitcoin spending structures are ignorant to addresses. Spending 5 coins from the same address is the same as spending 5 coins from different addresses. Didn't Eligius US fail yesterday because of this?  Disk space is consumed by shares, not balances (which are only kept in memory for a short period when it calculates a getwork). miner transfers 4 BTC to marketplace <-- probably a 0.01 BTC fee
miner transfers 2 BTC to marketplace <-- probably a 0.02 BTC fee[/color You can get much lower fees by using an Eligius branch. Qurashee made some Windows builds (use at your own risk! they might contain viruses, who knows), or you can build from source. |
|
|
|
|
Poll seems pretty straightforward. Please only vote if you mine on Eligius regularly, and actually understand the question.
Basically: should the pool pay you after you reach at least 0.16… BTC, or continue requiring a minimum of 1 BTC?
|
|
|
|
|
Show Posts
