Talk:Bitcoin/address validation: Difference between revisions
Content added Content deleted
(→Task definition: Trying to identify what's really needed…) |
|||
| Line 4: | Line 4: | ||
:: The bitcoin wiki is a more accurate source than wikipedia indeed. As far as whether it is "necessary" to have this task in RC: no, it is not. I don't think it would hurt, though. On the over hand, I know there are some political issues with the concept so I won't insist much if whoever is in charge here doesn't accept it, even as a draft.--[[User:Grondilu|Grondilu]] 04:07, 28 November 2012 (UTC) |
:: The bitcoin wiki is a more accurate source than wikipedia indeed. As far as whether it is "necessary" to have this task in RC: no, it is not. I don't think it would hurt, though. On the over hand, I know there are some political issues with the concept so I won't insist much if whoever is in charge here doesn't accept it, even as a draft.--[[User:Grondilu|Grondilu]] 04:07, 28 November 2012 (UTC) |
||
::: I'm not too worried about the narrowness of the task spec, just that it's possible to work out how to implement it without reading someone else's solution and that it is possible (even if not necessarily ''easy'') to verify the correctness without reference to someone else's code. If these are satisfied and we've got evidence of independent implementations, it's a good draft and can advance to being a full task. |
::: I'm not too worried about the narrowness of the task spec, just that it's possible to work out how to implement it without reading someone else's solution and that it is possible (even if not necessarily ''easy'') to verify the correctness without reference to someone else's code. If these are satisfied and we've got evidence of independent implementations, it's a good draft and can advance to being a full task. |
||
::::I've added more details in the description of the task. I'll add an example of a correct bitcoin address later. (a wrong one is easy to forge).--[[User:Grondilu|Grondilu]] 10:46, 28 November 2012 (UTC) |
|||
::: Of more interest though is whether there will be other bitcoin-related tasks in the future (specifically, the next 3 months; there's no point trying to plan further ahead than that). If not, the name of this one should change. That's independent of whether this is draft or not. –[[User:Dkf|Donal Fellows]] 09:09, 28 November 2012 (UTC) |
::: Of more interest though is whether there will be other bitcoin-related tasks in the future (specifically, the next 3 months; there's no point trying to plan further ahead than that). If not, the name of this one should change. That's independent of whether this is draft or not. –[[User:Dkf|Donal Fellows]] 09:09, 28 November 2012 (UTC) |
||
Revision as of 10:46, 28 November 2012
Task definition
Is there a link to the actual definition of what is a valid BTC address? The wikipedia link (at time of writing) doesn't say anything on the topic other than that it is “human readable” and “around 33 characters long” and “always starts with a 1 or 3”; that's far too vague for a Rosetta Code task! (Yes, I could try decoding some of the existing examples, but I greatly prefer to be able to independently code tasks if I can. Independent implementations help ensure that the task itself is properly possible.) A link for this sort of thing is entirely adequate for now. –Donal Fellows 00:16, 28 November 2012 (UTC)
- Not sure if This is the definitive thing. On the other hand though, is it really necessary to have a task with such a narrow range of application? --Ledrug 03:39, 28 November 2012 (UTC)
- The bitcoin wiki is a more accurate source than wikipedia indeed. As far as whether it is "necessary" to have this task in RC: no, it is not. I don't think it would hurt, though. On the over hand, I know there are some political issues with the concept so I won't insist much if whoever is in charge here doesn't accept it, even as a draft.--Grondilu 04:07, 28 November 2012 (UTC)
- I'm not too worried about the narrowness of the task spec, just that it's possible to work out how to implement it without reading someone else's solution and that it is possible (even if not necessarily easy) to verify the correctness without reference to someone else's code. If these are satisfied and we've got evidence of independent implementations, it's a good draft and can advance to being a full task.
- I've added more details in the description of the task. I'll add an example of a correct bitcoin address later. (a wrong one is easy to forge).--Grondilu 10:46, 28 November 2012 (UTC)
- Of more interest though is whether there will be other bitcoin-related tasks in the future (specifically, the next 3 months; there's no point trying to plan further ahead than that). If not, the name of this one should change. That's independent of whether this is draft or not. –Donal Fellows 09:09, 28 November 2012 (UTC)
- I'm not too worried about the narrowness of the task spec, just that it's possible to work out how to implement it without reading someone else's solution and that it is possible (even if not necessarily easy) to verify the correctness without reference to someone else's code. If these are satisfied and we've got evidence of independent implementations, it's a good draft and can advance to being a full task.
- The bitcoin wiki is a more accurate source than wikipedia indeed. As far as whether it is "necessary" to have this task in RC: no, it is not. I don't think it would hurt, though. On the over hand, I know there are some political issues with the concept so I won't insist much if whoever is in charge here doesn't accept it, even as a draft.--Grondilu 04:07, 28 November 2012 (UTC)
- Looking at this further (and peeking at the proposed solutions) the task appears to be to verify that the data is base58-encoded and that the computed check-digits match the supplied ones (which is basically following the bottom of this diagram, i.e., after the ripemd160 step). If this is the case, it is important to spell this out in the task definition rather than leaving it to people to guess. –Donal Fellows 09:40, 28 November 2012 (UTC)
