Pages:
Author

Topic: Developer Guide on bitcoin.org: writers/reviewers needed - page 3. (Read 7781 times)

sr. member
Activity: 285
Merit: 250
Bitcoin.org maintainer
Unfortunately, I'm still catching up so I'm afraid I cannot add much to this project yet.

Actually, reviews would be very useful at this point. If you can spot any confusing text, inaccuracies, typos, etc, please make a pull req or report them as an issue. That'll be very much appreciated.

Few suggestions:

- For new developers, maybe it makes sense to have a bit more general information. For example, using bitcoin-cli, RPC or using bitcoind as border router.
- Would it be an idea to have 'user contributed notes' under each section?

Thanks! Actually if you want to work on the API reference page, that should probably be it. As for the "user contributed notes", can you further explain your idea?
newbie
Activity: 22
Merit: 0
Thank you for this. (where is the donation address at the bottom of the page?)
Unfortunately, I'm still catching up so I'm afraid I cannot add much to this project yet.

Until now I found that documentation is all over the place and I honestly have no idea if I'm looking at recent or outdated specs. So hopefully, this will be the place where things stay updated.

Few suggestions:

- For new developers, maybe it makes sense to have a bit more general information. For example, using bitcoin-cli, RPC or using bitcoind as border router.
- Would it be an idea to have 'user contributed notes' under each section?


But thanks again. I think it's a great initiative.
sr. member
Activity: 285
Merit: 250
Bitcoin.org maintainer
Latest update: The first draft for the Transaction subsection is there:

(Merged)

Reviews are appreciated (only errors, omissions, confusions, and other issues at this point, writing style improvements can be done later ).
full member
Activity: 229
Merit: 103
We need a new wiki. New users can't edit it anymore and the page is very deprecated yet.

Please follow http://www.reddit.com/r/Bitcoin/comments/20b926/its_time_to_have_a_new_wiki/

@mesamunefire did it: http://thebitcoinwiki.com/index.php?title=Main_Page

But I think the community need more proof he can maintain that for a while.

 Huh
legendary
Activity: 1232
Merit: 1076
sr. member
Activity: 285
Merit: 250
Bitcoin.org maintainer
Please specify a license for contributors. I recommend the GNU Free Documentation License.
http://www.gnu.org/copyleft/fdl.html

The content on bitcoin.org is already under MIT (see the copyright notice at the bottom), which is a very permissive license (AFAIK, I'm no expert with licensing).
legendary
Activity: 1232
Merit: 1076
Please specify a license for contributors. I recommend the GNU Free Documentation License.
http://www.gnu.org/copyleft/fdl.html
jr. member
Activity: 50
Merit: 54
legendary
Activity: 1526
Merit: 1134
Question: Is it true that the miner can remove Input1 and Output0, add a new Output0, and mine the modified transaction?

Yes.

Quote
Question: Is it true that each signature in a multisig scriptSig can use a different hash type?

Yes.
jr. member
Activity: 50
Merit: 54
Mike:

Thank you for your answer.

I think I confused the issue by trying to generalize it and tie it into bitcoinj. Looking at a particular transaction with the form:

Code:
Input0|Input1||Output0

And...

*   Input0 is signed SIGHASH_NONE|SIGHASH_ANYONECANPAY (prevout script was pay-to-pubkey-hash)

*   Input1 is signed SIGHASH_ALL (prevout script was pay-to-pubkey-hash)

And...

*   The transaction is transmitted directly to a single miner who doesn't relay it

Question: Is it true that the miner can remove Input1 and Output0, add a new Output0, and mine the modified transaction?

---

Your answer did point out something I haven't seen documented elsewhere, so I want to make sure I understand correctly before documenting it myself:

Question: Is it true that each signature in a multisig scriptSig can use a different hash type?

Thank you again for your help! -Dave
legendary
Activity: 1526
Merit: 1134
At that stage of the protocol the signature being returned is signing for a CHECKMULTISIG output. The signature covers the outpoints, so you can't take it and apply it to any arbitrary coin (besides the keys are meant to not be reused, even though they are in the current code). The other signature for the multisig output is required and that covers the outputs.
jr. member
Activity: 50
Merit: 54
Hi,

I'm currently writing about OP_CHECKSIG for the dev guide and I could use a quick hint from someone more knowledgeable about the SIGHASH_NONE|SIGHASH_ANYONECANPAY hash type:

What prevents peers (relayers) and miners from extracting all inputs signed with SIGHASH_NONE|SIGHASH_ANYONECANPAY from a transaction and using those inputs to create new transactions that pay themselves?

I'm confused because, on one hand, bitcoinj's payment channels seem to use SH_N|SH_ACP, so I suspect Mike thinks it's secure, but on the other hand, I don't see how it could be based on the explanation of SH_N|SH_ACP on the wiki, which I understand to say:

* SH_NONE prevents signing of any outputs by the current input.

* SH_ANYONECANPAY prevents signing of any input except the current input

The combined effect being a valid input which can extracted and spent to an arbitrary script.

Any help will be appreciated,

-Dave
sr. member
Activity: 285
Merit: 250
Bitcoin.org maintainer
I can translate into Arabic, if you need help ?

You can refer to this thread for translations:
https://bitcointalksearch.org/topic/bitcoinorg-needs-more-help-with-translations-349633

Arabic translations indeed really need to be updated. Your help is more than welcome!
newbie
Activity: 38
Merit: 0
I can translate into Arabic, if you need help ?
legendary
Activity: 1526
Merit: 1134
Awesome! Let's go! Smiley
sr. member
Activity: 285
Merit: 250
Bitcoin.org maintainer
We definitely need a section on the payment protocol, which merges together all the BIPs and best practices into a living document. BIPs are great but they are written as "delta to previous behaviour" which can make figuring out the systems final state harder than it should be.

Yup, I called this subsection "Payment requests". Just let me know if you feel anything is missing (or isn't relevant enough to be mentionned).

I just updated the initial thread to provide clearer procedures and instructions for anyone to take part in discussions, submit work and see assigned tasks.
legendary
Activity: 1526
Merit: 1134
We definitely need a section on the payment protocol, which merges together all the BIPs and best practices into a living document. BIPs are great but they are written as "delta to previous behaviour" which can make figuring out the systems final state harder than it should be.
administrator
Activity: 3962
Merit: 3184
Interested as well. I'm also in the process of translating bitcoin.org on transifex.
jr. member
Activity: 50
Merit: 54
Right now there are two simple (but not necessarily easy!) ways to get started:

1.  Dip your toes in the water: work with Blockgenesis to refine the text we already have about the block chain. Blockgenesis has proposed a number of improvements (some small, some larger) and we need a writer/editor to implement those improvements.

2.  Jump into the deep end: agree to write a section of the outline Blockgenesis posted to above. The Block Chain section is written and I'm working on the Transaction section, but all the other sections are unclaimed. Just tell us what section you want and give us a rough idea about how long it will take you.

You can, of course, think up an option #3 and do that

Blockgenesis is currently co-ordinating everything, so let him know what you want to do and he'll give you access to the resources we're currently using.

-Dave (author of the block chain section in the OP link)
sr. member
Activity: 285
Merit: 250
Bitcoin.org maintainer
I will probably leave this to more technical hands but I might be able to find some good points here and there so reporting in

PM'd, thanks!
Pages:
Jump to: