Bitcoin Forum
May 26, 2024, 11:41:59 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 [2] 3 »
21  Bitcoin / Development & Technical Discussion / Re: Developer Guide on bitcoin.org: writers/reviewers needed on: April 12, 2014, 07:59:38 PM
Hi,

We could use a little advice about what's relevant to wallet authors when it comes to choosing which inputs to select for making a new payment.  We described three options:

* A merge avoidance algorithm makes it harder for outsiders looking at block chain data to figure out how many satoshis the receiver has earned, spent, and saved.

* A last-in-first-out (LIFO) algorithm spends newly acquired satoshis while there's still double spend risk, possibly pushing that risk on to others. This can be good for the receiver's balance sheet but possibly bad for their reputation.

* A first-in-first-out (FIFO) algorithm spends the oldest satoshis first, which can help ensure that the receiver's payments always confirm

We were thinking about cutting out FIFO because it doesn't seem very useful (except for being reliable and easy to implement).  We were further discussing whether we should cut out LIFO---which might be useful for some applications---in order to emphesize the privacy benefits of merge avoidance.

However, none of us writers/editors have any practical experience here, so we would appreciate some developer feedback about what you need to know.  Here's a direct link to the input-selection section and our GitHub discussion of the issue.

A quick trace of Electrum's source code (which I happend to have handy) made it seem like it used FIFO.

Thanks, -Dave
22  Bitcoin / Development & Technical Discussion / Re: Finally a question about Bitcoin that I could not answer. on: April 03, 2014, 03:32:20 PM
Hi, Jan.

We'd absolute love any help!  We're mostly guessing about what developers need to know, so feedback based on your experience with Mycelium would be hugely appreciated.  For example, what assumptions made by other documentation has tripped you up?[1]  Which BIPs have you found hard to understand?[2]  What important things just aren't documented elsewhere?[3]

Thanks!,

-Dave

[1] As an example of assumptions, one developer told us that the standard format for describing scripts is confusing to new devs because it doesn't mention the op-push-data codes that must be used.  It just assumes you know about them. We revised the documentation based on his feedback.

[2] As an example of finding documentation hard to understand, when I wrote a quick test implementation of BIP70, trying to figure out one particular sentence from BIP70 cost me three hours of time.

[3] I'm sure there are plenty of examples of undocumented things. :-)
23  Bitcoin / Development & Technical Discussion / Re: Finally a question about Bitcoin that I could not answer. on: April 02, 2014, 02:14:25 PM
Hi,

We've been working on a developer guide for Bitcoin.org which might be what you're looking for.  We have a forum thread, GitHub repository, and a demo site.

We're actively looking for writers and reviewers, so if you'd like to help, please see the forum thread above.

Thanks!, -Dave
24  Bitcoin / Development & Technical Discussion / Re: Developer Guide on bitcoin.org: writers/reviewers needed on: April 02, 2014, 02:08:23 PM
Hi,

The payment processing section (including BIP70 payment requests) has been added to the devguide.  Comments and suggestions are welcome on the pull request.

(Please comment there even though the pull request is closed.  Every comment posted will be read and replied to.)

Thanks to Saïvann's late-night efforts, you can read the new section in nicely-formatted HTML on the demo site.

General questions or comments should be sent here, the mailing list, or submitted as an issue.

Thanks!, -Dave
25  Bitcoin / Development & Technical Discussion / Re: Developer Guide on bitcoin.org: writers/reviewers needed on: March 31, 2014, 07:35:44 PM
Edit:  After reading through the Bitcoin Core source code for an embarrassingly long time, I figured out that this paragraph from BIP70,

Quote
signature: digital signature over a hash of the protocol buffer serialized variation of the PaymentRequest message, where signature is a zero-byte array and fields are serialized in numerical order (all current protocol buffer implementations serialize fields in numerical order), using the public key in pki_data.

means to do this:

Code:
request.signature = ""

before doing this:

Code:
request.signature = sign(priv_key, request.SerializeToString(), "sha256")

Thanks to everyone who read my previous post.
26  Bitcoin / Development & Technical Discussion / Re: Developer Guide on bitcoin.org: writers/reviewers needed on: March 17, 2014, 07:20:01 PM
Thanks!
27  Bitcoin / Development & Technical Discussion / Re: Developer Guide on bitcoin.org: writers/reviewers needed on: March 17, 2014, 01:44:18 PM
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
28  Bitcoin / Development & Technical Discussion / Re: Developer Guide on bitcoin.org: writers/reviewers needed on: March 17, 2014, 03:23:40 AM
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
29  Bitcoin / Development & Technical Discussion / Re: Developer Guide on bitcoin.org: writers/reviewers needed on: March 12, 2014, 06:43:39 AM
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)
30  Bitcoin / Bitcoin Technical Support / Re: Why does "createrawtransaction $(decoderawtransaction $hexString)" not work? on: February 15, 2014, 03:15:43 AM
Fair enough.  Although now if you get bored, you can be the person who codes up a simple web service that stores locktimed transactions and broadcasts them when appropriate.  :-)
31  Bitcoin / Bitcoin Technical Support / Re: Why does "createrawtransaction $(decoderawtransaction $hexString)" not work? on: February 15, 2014, 01:50:39 AM
Not being able to broadcast it before the effective date may be less cool, but it's not any less functional.  I use locktime to send money to myself in the future---sort of like buying myself a savings bond.

The sequence number lets you publish multiple versions of a transaction. The network is supposed to drop a pending transaction when another transaction appears spending the same input but with a higher sequence number.  Sequence number and locktime are both currently used for payment channels as implemented in bitcoinj.  See the following link for details:

    https://en.bitcoin.it/wiki/Contracts#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party

I'm curious: what cool thing did you want to do with locktime that you can't do now?
32  Bitcoin / Bitcoin Technical Support / Re: Why does "createrawtransaction $(decoderawtransaction $hexString)" not work? on: February 15, 2014, 12:51:27 AM
I assure you, you can set sequence to non-max. Here's a locked transaction I sent myself last week:

    https://blockexplorer.com/rawtx/5af2104b1d7f9524f9bb2d5b81e79e7d6e3b21cb5552e31a96a24a7adc3344c7

Note that since early 2013, the memory pool will not accept non-finalized transactions in order to prevent DOS attacks. This may be the source of your error. Try sending the transaction when the locktime/lockblock is in the past.
33  Bitcoin / Bitcoin Technical Support / Re: Why does "createrawtransaction $(decoderawtransaction $hexString)" not work? on: February 14, 2014, 08:54:34 PM
Automatic:

I just saw your post. The reason your transaction went through immediately was that the sequence number of all inputs was set to the maximum value (4294967295), indicating the transaction was finalized and the locktime didn't apply.

Changing any sequence field to any number less than the maximum will prevent the transaction from being entered into a block until the locktime (or, in your case, lockblock number) passes.

I got tired of changing locktimes manually, so I wrote a quick shell script that changes the locktime to an arbitrary date and sets the sequence number to zero. The script then does some quick validation of the resulting transaction to help prevent me from doing anything simple.

I added some comments to the script to help explain what's going on, but let me know if you have any questions.  Note: I haven't tested it on multiple-input transactions.

Code:
#!/bin/bash -eu

BITCOIND="bitcoind"
#BITCOIND="bitcoind -testnet"

if [ $# -ne 1 ]
then
    echo "Command to change the locktime of a bitcoin transaction provided on standard input"
    echo "  Usage: ... | $0 '<date>'"
    echo "  Example: btc-spend-all | $0 'tomorrow'"
    exit 1
fi

## I usually use this script in a pipeline with btc-spend-all, i.e.:
##    btc-spend-all | btc-change-locktime tomorrow | bitcoind signrawtransaction $(cat)
## or
##    echo '01000000017f286f35362457e961925835bff28351e0b679c7810827396c76967712a6714d0000000000ffffffff0100e1f505000000001976a9144c56a8926eeb911b06575be05bad06e66463fb1e88ac00000000' | btc-change-locktime
## Load the raw transaction from standard in
RAW_TRANSACTION=$(cat)

## Get the desired locktime in human-readable format and convert it into
## epoch time in both decimal format and little-endian hexadecimal format
LOCKTIME_DECIMAL=$( date +%s -ud "$1" ) || { echo 'Invalid date' ; exit 1 ; }
LOCKTIME_HEX=$( echo $LOCKTIME_DECIMAL | awk '{ printf "%x", $1 }' | sed 's/^\(..\)\(..\)\(..\)\(..\)/\4\3\2\1/' )


#### SAMPLE TRANSACTION
# 01000000017f286f35362457e961925835bff28351e0b679c7810827396c76967712a6714d0000000000ffffffff0100e1f505000000001976a9144c56a8926eeb911b06575be05bad06e66463fb1e88ac00000000
#### Every two characters (char) in hex equals one byte
# 01000000 .............................Version (8 char)
# 01 ...................................Vin count (2 char)
# 7f286f35362457e961925835bff28351e0b679c7810827396c76967712a6714d ...Prevout hash (64 char)
# 00000000 .............................Prevout index (8 char)
# 00 ...................................Signature script length (2 char)
# ffffffff .............................**Sequence number** (8 char)
# ++++++++++++++++++++++++++++++++++++++[[[[ additional inputs can go here ]]]]
# 01 ...................................vout count (2 char)
# 00e1f50500000000 .....................satoshis to transfer to send in this output (16 char)
# 19 ...................................public key length (2 char)
# 76a9144c56a8926eeb911b06575be05bad06e66463fb1e88ac public key claim script (50 char)
# ++++++++++++++++++++++++++++++++++++++[[[[ additional outputs can go here ]]]]
# 00000000 .............................**locktime** (8 char)

## Modify the transaction
MODIFIED_TRANSACTION=$(
    echo $RAW_TRANSACTION | sed '''
        ## createrawtransaction by default creates transactions with
        ## max-value sequence numbers, which prevents locktime from having
        ## any effect. We need to change one of these sequence numbers to a
        ## lower value. Since the first sequence number always appears in
        ## the same byte location within the encoded transaction (after 84
        ## hexits), we will reduce it down to zero.
        s/\(.\{84\}\)ffffffff/\100000000/;

        ## Now we need to set locktime to the earliest date when we want to
        ## be able to spend the bitcoins. Locktime is always the last 8
        ## hexits of the encode transaction, and by default it is set to zero.
        s/00000000$/'$LOCKTIME_HEX'/;
    '''
)

## Pre-build the decode command so we can reuse it several times
_dc_cmd="$BITCOIND decoderawtransaction"

## Now lets diff the original and modified transactions to test for changes.
## The diff should always produce 11 lines of output: a two-line header
## listing the file names, three one-line headers for each changed part,
## and three two-line diffs
_diff_line_count=$( eval diff -u0 <( $_dc_cmd $RAW_TRANSACTION ) <( $_dc_cmd $MODIFIED_TRANSACTION ) | wc -l )
if [ $_diff_line_count -ne 11 ]
then
    echo Unexpected output from the diff command.  Dying...
    exit 1
fi

## Now test that all of the expected changes were made
eval diff -u0 <( $_dc_cmd $RAW_TRANSACTION ) <( $_dc_cmd $MODIFIED_TRANSACTION ) \
        | egrep -v  '^(---|\+\+\+|@@) '  \
        | sed '''
            ## Whitelist all of the expected changes in the diff by
            ## deleting them so we can then test for unexpected changes
            #
            ## The new locktime should decode to the decimal locktime
            /^+.*"locktime".*'$LOCKTIME_DECIMAL'/d;
            ## The old locktime should have been zero
            /^-.*"locktime".* 0,/d;
            ## The new sequence should be zero
            /^+.*"sequence".* 0$/d;
            ## The old sequence should have been the maximum, 4294967295
            /^-.*"sequence".* 4294967295/d;
            ## The only thing left should be the automatically-computerd
            ## txid hashes
            /"txid" : /d

            ## If anything remains, somenthing went wrong
        ''' | grep . && { echo "Unexpected changes.  Dying..." ; exit 1 ; }

## If we get here, all of the tests have been passed, so give the user
## the modified transaction so they can sign it
echo $MODIFIED_TRANSACTION
34  Bitcoin / Development & Technical Discussion / Re: Improving Offline Wallets (i.e. cold-storage) on: March 28, 2013, 08:15:54 PM
Ah, I retract my suggestion.  A particularly crafty virus could infect the media device, install an autorun file, and get the device to switch from MTP mode to USB mass storage mode between the time it disconnects from the online (hot) computer and connects to the offline (cold) computer.  -Dave
35  Bitcoin / Development & Technical Discussion / Re: Improving Offline Wallets (i.e. cold-storage) on: March 28, 2013, 01:33:38 AM
Hi, Alan, and thanks for the wonderful work you do on Armory.

A portable media player which connects to the host computer in MTP mode might offer reasonable security and convenience:

    + Files need to be downloaded from the device to the host computer's OS before processing, so files accessed through MTP cannot be automatically executed on Windows[1] or Linux[2], blocking most viruses.

    + There are plenty of cheap MTP-enabled used MP3 players on eBay.

    + Uses standard USB connections found on practically all computers.

    + Runs at high speed for transferring media files, so small transaction info will transfer almost instantly.

    + On Windows and novice-friendly Linux distros, unprivileged apps can by default write to MTP so Armory doesn't need root access.

    + Open source MTP library and tools for Linux: http://libmtp.sourceforge.net/

    + Possible sample code for MTP support on Windows: http://addons.songbirdnest.com/addon/172

    - GNOME Virtual FS (GVFS) and probably Windows may autoload thumbnails and other metadata from MTP devices, creating possible attack vectors.  Removing the MTP GVFS module on an offline Linux machine would prevent autoloading there and not otherwise affect the user (unless he used MTP for other things on that machine).

Also notable:

    +/- Wikipedia seems to say that Windows can't do arbitrary autorun from non-volume devices such as MTP[3], but I recommend testing for verification.

    +? There's MTP over Bluetooth[4], which may provide an enhancement at minimal extra development cost (your time) for those users willing to tolerate a network connection.

I knew practically nothing about MTP an hour ago and the above points summarize everything I now know, so take it all with a grain of salt.

Thanks again for your work,

-Dave

[1] http://portableapps.com/node/3292
[2] http://intr.overt.org/blog/?p=153
[3] https://en.wikipedia.org/wiki/AutoPlay#Non-volumes
[4] https://en.wikipedia.org/wiki/Media_Transfer_Protocol#History
36  Economy / Economics / Re: Bitcoin Austrian Economic Study Group on: December 21, 2010, 07:33:25 AM
I don't have time to start reading the week before Christmas, but I'm in for next week.

Also, I think these chapters are too long for one chapter a week.  What do you think about reading a constant 20 or 30 pages a week?  (Or 21 and 28 pages a week for 3 or 4 pages a day.)

-Dave
37  Economy / Economics / Re: Bitcoin Austrian Economic Study Group on: December 12, 2010, 05:16:15 AM
In the meantime, I suggest we come up with a guide on how to approach our reading...

While reading, if you have any questions or doubts, write them down.  Then continue reading to the end of the chapter and see if your questions are answered and your doubts eliminated.  If either remain, post them here.

At the end of each chapter, each participant should post here at least one paragraph about what they thought was most important in that chapter.  (More than one paragraph is fine.)

I suggest for convenience that we reference the in-text page numbers and paragraphs in the PDF edition at http://mises.org/books/mespm.pdf.
38  Economy / Economics / Re: Bitcoin Austrian Economic Study Group on: December 10, 2010, 07:32:21 PM
Why not Rothbard's Man, Economy and State? [...]

We do not need to choose between Human Action and Man, Economy, and State--we can choose to read both in sequence.
39  Economy / Economics / Re: Bitcoin Austrian Economic Study Group on: December 10, 2010, 05:41:00 PM
Human Action isn't exactly light reading.  I would suggest that aspiring Austrians start with books aimed at for the general public, such as Economics in One Lesson and the 'Uncle Eric' series starting with Whatever Happened to Penny Candy.  The former is aimed at lay adults, the latter at teens and pre-teens; [...]

I do love Economics in One Lesson, but what bitcoin user needs help understanding books written for lay adults and children?  Those books stand on their own--that is their purpose.

If the point of this group is to help us learn more together than we would learn by ourselves, then a challenging book must be selected.  Human Action is challenging; it is not light reading--but it is damn informative; it has changed the thinking of some of the best thinkers; it brought back to life a dead school of economics; and it is today the rock upon which the entire Austrian School stands.  I can think of no better book with which to begin this group's studying.

-Dave
40  Bitcoin / Bitcoin Discussion / Re: How To Force Sites To Accept Bitcoin! on: December 10, 2010, 07:51:04 AM
BitCoinMail says the same thing about unredeemed bitcoins in its FAQ (and has for months):

"What happens to BitMail that isn't redeemed?

"Recipients have 14 days to redeem their BitMail. In the rare case that a BitMail is not redeemed after that time, the bitcoins will be used to support the site and help ensure that BitMail is always free."

-Dave
Pages: « 1 [2] 3 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!