text:
Segwit: Arbitrary data storage in witness?
Let's say I want to encode the text of the King James version of the Bible into the block chain, one piece at a time (replace this with any zany idea to consume copious quantities of block space). OP_RETURN is impractical because I can only work with 80-byte chunks.
I notice that SegWit allows much more data to be stored - up to 3 MB/block - in witness data.
Clearly, I can't use a V0 witness program because my witness data must take the form
<signature> <pubkey>

However, I believe I can use a V1 witness program. Scripts with that version won't be supported immediately after SegWit deployment, but I notice this in BIP-141:

If the version byte is 1 to 16, no further interpretation of the witness program or witness stack happens, and there is no size restriction for the witness stack. These versions are reserved for future extensions.

So here's my plan. I'm going to create an output script of the form:
<0x01> <0x0000>

This is a V1 witness program. According to BIP-141, the witness program is not to be interpreted, and the subsequent witness stack will have no size restriction.
Then I'm going to spend that output with a witness transaction input. The witness of my transaction encodes a thousand bytes of text.
When I publish this spending transaction, it will be propagated by nodes. They can't reject it as invalid because that would break forward compatibility when V1 scripts are introduced. BIP-141 says nothing about whether or not such transactions should be relayed (nor does BIP-144), so I assume they will be.
As long as I pay a sufficiently high fee, my transaction should eventually be mined. I even get a 75% discount over using OP_RETURN because my text is encoded in the witness.
And there's nothing the protocol will do to stop me. Or is there?
Edit: to make things simple, assume SegWit has been widely-deployed and that most nodes understand V0 witness programs. Clearly, non-SegWit nodes will not relay a witness transaction because it will be considered non-standard. I'm interested in the behavior of SegWit nodes.

How did this age after SegWit adoption?

@CSᵠ see ordinals...

Your transaction, although not invalid, is non-standard. Since it is non-standard, it will not be propagated and will be rejected for being non-standard. However this does not mean that it cannot be included in a block; it can. It only requires that the miner and all of the nodes between you and that miner must be running some software that accepts and relays non-standard transactions. However not many nodes actually do, so you may have a hard time getting good propagation of your transaction.

Non-standard for a segwit node or a non-segwit node? If segwit nodes consider such a transaction non-standard, where is that stated in the documentation?

Segwit is constructed in such a way that every SegWit spend is non-standard to non-segwit nodes.

@PieterWuille, of course. But how would a segwit node that only understands V0 witness programs respond to my attack?

Future witness versions are non-standard by policy in Bitcoin Core for precisely the reason you point out. This is generic: all constructions that exist which are intended for future extensibility are treated as non-standard (for example, also the OP_NOPx opcodes).

@RichApodaca standardness for outputs is defined by this function here: https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.cpp#L72. The solver function that is called will end up at this if block: https://github.com/bitcoin/bitcoin/blob/master/src/script/standard.cpp#L71. From that code, you can see that any non v0 witness output will return false in the solver which then causes IsStandard to return false too, indicating that non v0 witness outputs are non-standard. The same happens here for inputs https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.cpp#L161

Thanks @PieterWuille. It looks like what I was missing is that all upgradeable behavior is marked as non-standard implicitly, so there's no need to document this in the SegWit BIPs.


text:
What's the easiest/fastest way to experiment with bitcoin-cli?
I want to experiment with the bitcoin-cli in the easiest way.
I just installed bitcoin core and waiting for it to download the blockchain.
Is there a way meanwhile I can run bitcoind and/or bitcoin-cli, that doesn't require downloading the whole blockchain?
I guess running the test-net is a natural approach.
My main problem is: I don't see the bitcoind and bitcoin-cli executables anywhere on my system.
I'm running Ubuntu 16.04.1 LTS
and installed bitcoin core through the command line as described here:
http://bitzuma.com/posts/getting-started-with-bitcoin-core-on-ubuntu/
ultimately running bitcoin-qt from the command line.

Please don't include "side notes" in questions - ask it as a separate question, otherwise it will likely get overlooked or removed.  When you do ask a new question, be sure to explain what OS you are using, the Bitcoin Core version, and how you installed Bitcoin Core (e.g. where you got the packages).

Alright, my problem was simply that the link I mentioned didn't mention bitcoind needed to be installed in addition to bitcoin-qt to get access to bitcoin-cli. So I just needed to do:
sudo apt-get install bitcoind

Yes, you can run bitcoind with the -testnet option.  This starts a separate process that runs independently of the mainnet bitcoind.  You can control it with bitcoin-cli -testnet.
Note that you will have to download and verify the testnet blockchain before being able to do very much.  This also takes some time / bandwidth / disk space / CPU, though much less than for mainnet.  Depending on the speed of your CPU and Internet connection, it might also make the mainnet download take longer if they have to share resources.

The problem is I don't see a bitcoin-cli or bitcoind executable although I downloaded bitcoin core. Perhaps it creates them only when it finishes downloading the blockchain?

As I said, that is a separate question.

OK revised question to address my main concern more accurately

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

sort: votes


text:
What is the "witness reserved value" for BIP-141?
BIP-141 defines a witness reserved value as part of a flexible commitment structure:
Double-SHA256(witness root hash|witness reserved value)

The purpose is to support commitments (i.e., data associated with a block) beyond the witness root hash. That part makes sense, but it seems like the value of witness reserved value should be defined in BIP-141. For example, should it be omitted altogether when hashing the witness root hash? Should it be set to 0x00? Some other value?

It's a reserved value.
That means it is reserved for future extensions, but for now there are no rules about it. It's encouraged to not use it for anything, as that may conflict with later use.

When creating a coinbase Null Data output, what value does the miner use for "witness reserved value" given that a hash for (witness root hash|witness reserved value) is required?

Any value at all is allowed.

It seems that a node must know the witness reserved value used by a miner in order to properly validate the commitment in the coinbase output. The commitment is defined in terms of the double SHA-256 of (witness root hash|witness reserved value). In other words, the commitment in the coinbase output depends on the value of witness reserved value chosen by the miner. Yet this value doesn't appear anywhere explicitly. I'm missing something, but what is it?

The value is included in the coinbase witness, so every validating node knows it. It can be any 32-byte value, though.

Thanks - I think I found it: "the coinbase's input's witness must consist of a single 32-byte array for the witness reserved value." In other words, the value of "witness reserved value" is found in the coinbase transaction's witness. A coinbase transaction has only one input, so its only witness field contains the "witness reserved value" as its only item. Right?

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
Birthday attack on P2SH
The Segwit Benefits document has this to say about P2SH security for base transactions:

Multisig payments currently use P2SH which is secured by the 160-bit HASH160 algorithm (RIPEMD of SHA256). However, if one of the signers wishes to steal all the funds, they can find a collision between a valid address as part of a multisig script and a script that simply pays them all the funds with only 80-bits (280) worth of work, which is already within the realm of possibility for an extremely well-resourced attacker. (For comparison, at a sustained 1 exahash/second, the Bitcoin mining network does 80-bits worth of work every two weeks)

It then goes on to state:

Segwit resolves this by using HASH160 only for payments direct to a single public key (where this sort of attack is useless) ... [my emphasis]

Why does this document seem to imply that the birthday attack only works for multisig P2SH and then only for one of the signers?
It seems this attack works for anybody who sees the P2SH output on the block chain and decides to start hashing. If an attacker can generate an alternative redemption script that happens to hash to the value given in a P2SH output, s/he can make the redemption script do anything.
Am I misreading the document or misunderstanding the nature of the birthday attack?

Why does this document seem to imply that the birthday attack only works for multisig P2SH and then only for one of the signers?

The birthday attack (to the best of my knowledge) requires that the P2SH address is constructed from a script which involves both a key of the victim and the attacker. That is typically only the case for multisig, but is not technically restricted to it. It does not apply to single-key scenarios.

If an attacker can generate an alternative redemption script that happens to hash to the value given in a P2SH output

That is called a preimage search, not a collision search.

Preimage search: given a hash H, find X such that Hash(X) = H.
Collision search: find an X and a Y, such that X != Y and Hash(X) = Hash(Y).

A preimage search for a 160-bit hash function needs 2160 steps. A collision search however only needs 280 steps.

Am I misreading the document or misunderstanding the nature of the birthday attack?

I believe you are. I'll start with explaining a simplified (infeasible) attack in a 2-of-2 multisig situation, and then optimize it and generalize.
Example
Say you (A) and me (B) are engaging in a 2-of-2 escrow. This means that someone (possibly one of us) is going to send money to a 2-of-2 multisig script, requiring that both of us agree before it can be spent.
In order to do so, we must first agree on what that script is going to be. You have revealed your public key A to me, and are waiting for me to respond with mine.
Instead of just giving you the key B, I generate a huge list of 280 public keys, all of which I know the private key for.
For each of those keys K, I compute:

Hash160(A-and-K)
Hash160(B-and-K)

I put all the A-and-K hashes in one list L1, and all of the B-and-K hashes in a list L2. I sort both lists. Then I go through both lists, and find a hash that exists in both in a single iteration. This is the critical point. It is likely that such a collision exists, because even though there are only 280 entries in each list, there are 2160 combinations of entries. Each of those has a 2-160 chance to be a collision. This is also the explanation of the Birthday Paradox, and such an attack is therefore called a birthday attack.
So, say I have found a hash that occurs in both lists. Say that K1 is the key that generated the hash in L1, and K2 is the key that generated the hash in L2. In other words, Hash160(A-and-K1) = Hash160(B-and-K2).
Now I just tell you that my key is K1. You cannot disprove that, as in fact, K1 is a completely valid key of mine. You happily accept that, and we both agree on using the script A-and-K1. We construct the address Hash160(A-and-K1), which I already know is identical to Hash160(B-and-K2).
We hand out that P2SH address, and the payer sends money to that hash's address.
Once funds have been sent there, I can spend them without your cooperation.
The requirements for spending a P2SH outputs are:

(1) a redeemscript whose hash equals the Hash160 in the P2SH address
(2) inputs to that redeemscript that make it evaluate to true.

For (1) I can use the B-and-K2 script, and for (2) I can simply sign with both B and K2, both of which I have the private keys for.
Making it practical
In practice, the above attack is not feasible, because the lists L1 and L2 are too large to store (much less sort them) for current day hardware. However, cycle-detection algorithms can be used to find a K1 and K2 such that Hash160(A-and-K1) = Hash160(B-and-K2) in 280 steps without ever fully storing or sorting the lists L1 and L2.
Generalizing
The attack can also be generalized for other scripts where multiple people are involved, as long as the attacker has an influence over the chosen script.
Mitigation
SegWit does no longer have a 160-bit script hash system. It still uses 160-bit hashes for the single key case (for efficiency reasons), as the birthday attack does not apply to them. Instead it introduces P2WSH, which uses 256-bit script hashes. The birthday attack still applies there, but requires 2128 steps rather than 280. 2128 is considered infeasible to attack in the short to medium term. Furthermore, it is the security target for Bitcoin in general (including forging signatures), doing more is not very valuable.
Why is this not an issue for single-key addresses?
In the case where no input from the attacker goes into the creation of the address being stolen from, this attack doesn't work.
All the attacker has in this case is an address. He can't insert variance into it to produce 2160 combinations out of 280 attempts. The only thing that works here is a preimage attack, which needs 2160 iterations for a 160-bit hash.

Why does this document seem to imply that the birthday attack only works for multisig P2SH

It does not just apply to multisig, but to any P2SH output. The reason the attack does not apply to P2PKH and P2WPKH outputs is that those have a built-in signature checking operation in the output script itself. This means that the data that is hashed to compare to the hash specified in the output will be treated as a public key and the data before it will be treated as a signature. Thus you would need to find a private key which has a public key that hashes to the hash160, and that is far more difficult to do than just generating a colliding hash160.

and then only for one of the signers?

You are misreading this. The page uses that as an example since most people are most familiar with P2SH as being multisig and not just scripts. This attack is a problem for all P2SH outputs.
Edit: As Pieter mentions below, the birthday attack is only applicable when multiple parties are involved. This is because the attacker and his victim(s) must be involved in the creation of one script, the legitimate script.

The birthday attack requires that the attacker and the victim are both involved in the construction of the script. So while it does not only apply to multisig, but it does require multiple parties to be involved in the construction of a single script (which in practice means multisig). It does not apply to single-key P2SH.

How so? Couldn't one party create a script which collides with any hash160 for a P2SH output?

That's a preimage search, not a collision search, and needs 2^160 of work. The 2^80 birthday attack only applies to collision search (find two scripts that hash to the same thing), not to a preimage search (find a script that hashes to a given hash).

Ah, yes. I always seem to get those two confused :)


text:
Is it necessary for blocks to record the nBits difficulty parameter?
The next difficulty to solve a block is determined from how fast blocks were solved before it. In addition, the difficulty only changes once every two weeks or so.
So, couldn't every node keep track of the expected difficulty and not need to have it in each block header? Or is there a reason nodes need to be communicating the current difficulty in each block? Not that it would be a major savings, or anything, it just seems strange that this is included when it's just a function of all the other pieces of a chain.
Maybe it's because calculating nBits would take a long time eventually if you had to go through all the block headers every time you wanted to calculate the next difficulty?

Recall from the Nakamoto Whitepaper that for Simplified Payment Verification (SPV) clients, security is measured mainly by the amount of work done to secure a particular transaction.  SPV nodes can't use past headers alone to verify that an incoming payment is valid, so there's technically not much need to store past headers[1].
Of course, if you're not going to store all the headers, you need some way to measure difficulty for the headers you do have---and nBits provides that.
Note that storing recent headers can increase an SPV client's security by allowing it to calculate proper difficulty for later headers.  This ensures an attacker trying to lie to the client has to create proper-difficulty blocks.  Still, a complete headers chain isn't needed here, so nBits is still useful as a starting value.
[1] But BitcoinJ and all other SPV clients I know about still do store complete headers.  At a guess, the reason they do is to help them detect chain re-organizations (reorgs) that would render a previously-received payment invalid.

so there's technically not much need to store past headers What about unconfirmed transactions? You need to look into past blocks to confirm that their inputs are valid.

An essential part of verifying inputs are valid is ensuring that the input (previous output) hasn't been spent yet on the block chain.  SPV clients are incapable of doing that since they don't process the complete block chain.  SPV clients can only verify the unspentness of inputs for which they control the private keys (wallet transactions), so they're completely dependent on their full node peers for information about unconfirmed non-wallet transactions---if all their peers lie, the SPV client can be fooled.

Added a new paragraph to my answer describing how a partial headers chain can be superior security to not storing a headers chain, and why this still means nBits is useful.

doc says a spv client downloads the headers of blocks, but not full blocks; if they download block headers then they can calculate difficulty by themselves; i still dont see why it should be included as a block header field; and nothing mentions how to validate that field;

A small update: for clients that follow headers-first synchronization (introduced in Bitcoin Core 0.10), the nBits value in headers isn't actually useful anymore (it's always known before a header or block is received already).

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Is there a Counterparty Whitepaper?
Is there a Counterparty whitepaper? What about a specification?

There is a counterparty whitepaper: https://github.com/CounterpartyXCP/Counterparty

This link is no longer valid, please verify the link.

Link is broken.

The link you provided seems dead by now but there is an online documentation available at http://counterparty.io/docs/about_counterparty/.

Go to https://github.com/CounterpartyXCP/Documentation/ and search the repo for "protocol specification" (or API or whatever).
The current link for the protocol specification is https://github.com/CounterpartyXCP/Documentation/blob/master/Developers/protocol_specification.md

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
What are colored coins?
What exactly are colored coins? I've tried understanding, but I don't quite get it yet . . . Do any examples exist?

Colored coins are a method to track the origin of bitcoins, so that a certain set of coins can be set aside and conserved, allowing a party to acknowledge them in various ways. Such coins can be used to represent arbitrary digital tokens, such as stocks, bonds, smart property and so on.
The colored coins protocol is decentralized just like Bitcoin, but the current effort to develop an implementation is done under the BitcoinX project (tentative name), which also aims to provide some related services.
As this is still under development, you will not find any existing examples.
You can read more about it in Overview of colored coins (work in progress).

Meni - do you have a list of whitepapers you've written? I thoroughly enjoy reading them.

@makerofthings7: Thanks!  The list is quite short actually, in addition to colored coins there's AoBPMRS (https://bitcoil.co.il/pool_analysis.pdf) and double-spending https://bitcoil.co.il/Doublespend.pdf. There are a few papers I collaborated on but are not really mine. I also have a blog, http://fieryspinningsword.com/. And of course my vanity thread lists some of my more meaningful forum posts (https://bitcointalk.org/index.php?topic=121314).

I'm curious if you have any modifications to a proof of stake...e.g. if you embrace any new ideas of others not in your whitepaper.  That will be my next area of study.

wow...lots of great things in your posts!

@makerofthings7 - Not "new", I designed one of the original PoS implementations back in early 2012, much better IMO than the half-assed designs you see in various coins these days - https://en.bitcoin.it/wiki/Proof_of_Stake#Meni.27s_implementation. I'm also collaborating with Iddo Bentov on the Proof of Activity variant.

I read that wiki, and another post by you saying that you eventually warmed up to Cunicula's implementation more than your own.  I haven't yet seen an explanation of NXT or the other POS coins, but am passionate about finding a "green" way of solving the proof of work issue.  Have any links on Proof of Activity?

@makerofthings7: The main problem with what passes for "Proof of Stake" coins is that there is nothing at stake - The stakeholder has no reason not to extend all branches, thus being a rubber stamp of no use in combating double-spending. Since PoA is in the process of academic publication I can't link to the paper, but there's some related discussion on the forum - https://bitcointalk.org/index.php?topic=102355.

I'm reading about Bitshares now, not sure if it's related to your work, but I get the jist, not sure if that is your preferred approach.  Will read the forum now.


text:
why not change bitcoin consensus code to reject transactions sent to previously used addresses?
Bitcoin has a growing issue of UTXO dust. Usually this dust occurs from companies trying to track bitcoin use, by sending dust or small transactions to previously used addresses.
There is almost no benefit from allowing this to continue and many disadvantages as it reduces security and anonymity.
We also now have easy ways to avoid address reuse by using Hierarchical Deterministic wallets, so there is no reason that I can see for allowing address reuse to be permitted within the consensus code.
Therefore, why don't bitcoin developers change the code to reject these transactions and hopefully allow the UTXO to start decreasing in size?

There are three major reasons I can think of for not implementing this change.
First, it would massively impact transaction validation. To fully validate transactions, you only need to store the UTXO set (set of all unspent transaction outputs), which is currently a few gigabytes in size. If you wanted to disallow address reuse by consensus, you'd also need to keep track of every address (more accurately, output script) that has ever been used, which is a lot more data that also grows at a faster rate than the UTXO set.
Second, this would allow anyone to invalidate an unconfirmed transaction by sending a dust amount to one of its output addresses and getting their transaction confirmed first. This would completely break any off-chain protocol including Lightning.
Third, changes to the Bitcoin protocol generally add features, not remove them. It wouldn't be nice to people who rely on address reuse to remove this feature from under them.


text:
Turing completeness of Bitcoin Script
For me, scripts are one of the most interesting features of Bitcoin. They provide possibilities which have no equivalent in classical currencies. However, the wiki states

It is purposefully not Turing-complete, with no loops.

What's the rationale behind this decision?
Are there any proposals for useful contracts which would only be possible in a Turing complete script implementation?
Are there any alternative crypto currencies with Turing complete scripts? If so, how do they solve the problems from 1?

If scripts were Turing-complete, you could construct a fairly short script that took an extremely long time to run (a la the Busy Beaver) or contained an infinite loop.  This would tend to result in a denial of service against everyone on the network, when they tried to verify the transaction.
And there would be no general way to tell whether a script would loop infinitely or would eventually finish: that's the halting problem.
One could try to avoid this by including some sort of cutoff on how long a client will spend verifying a transaction, but it would have to be done very carefully so as to be consistent across all clients: if some accept it and others don't, the block chain will fork.
It seems simpler to avoid the situation all together.

If there was a limit, it would be better to have a limit on how many instructions could be executed rather than time spent, to ensure consistency

@RentFree: Which essentially reduces to what we have now.  If the script you want has a loop that is guaranteed to finish within a certain number of instructions, you can unroll the loop into a straight-line script with a fixed number of instructions.  Actually, as it stands, the number of instructions you execute, the number of bytes in the script, and the fee you pay, are all approximately proportional.

authors: Александр Викторович


text:
Is it possible to know my ip address by simply connecting to the Bitcoin network?
It is saying that in order to stay anonymous, it is usefull to use Tor whenever connecting to the Bitcoin network.

How does someone can discover my ip adress if I'm simply connecting
to the bitcoin network through bitcoin-qt without doing any
transaction ? (I assume the IP are display only during bitcoin
transaction)
Let's say the only transaction i'm doing is receiving bitcoin with
bitcoin-qt (not sending) and without using Tor. Does my identity is
also exposed ?

A tcp connection requires an exchange of packets, and every packet you send contains your IP address. (If it didn't, how could the remote host ever reply to you?)

Okay Nate Eldredge thank you that was usefull. As this is not the same question, do you know where I can find a tutorial which is explaining how to see "live bitcoin exchanging packet" ?(without using website like blockchain.info). I'm having some lack of knowledge relating to specific keywords, I can't find it on google.

http://www.coindesk.com/eavesdropping-attack-can-unmask-60-bitcoin-clients/

First, it's worth noting that getting your IP won't identify your wallet address. So they can't connect to you and then look you up on the blockchain to see who you've been trading with. Associating an address with a person takes normal investigation, like searching your computer or associating you/your IP with a post on the internet containing your address.
For 1:
Unless someone logging the connections to their bitcoin client and they decide to make it public, there isn't any public record of it.
That said, what most would be worried about isn't that their IP would be publicly published, but that certain organizations may be able to identify them. One way these organizations could identify you is by running their own bitcoin client and logging their internet traffic (TCP on the port BTC uses). This would be very easy to do, so if it is something you're concerned about, you should assume it is being done. (If you want to know how easy, look up wireshark. It can log all traffic on your local network.)
Assuming someone is logging IPs on the bitcoin network, the only hope of not being logged is that a singe node only connects (on average) to around 8 peers (but this is configurable). This small number means you have a somewhat small chance of connecting to them.
But, depending on how peer discovery works, it may also be possible to be found by the logger asking for peers. That is, there has to be some way of finding peers in the btc network. This could possibly be exploited to identify a large number of IPs connecting to the btc network. (To be explicit, I haven't studied the specific way peer discovery works, but from general understanding of programming and networks, it seems very plausible.) If this were the case, then the fact that a node only connects to about 8 peers is pointless, because you wouldn't need to connect directly to the organization to get logged; they could find you by asking others for new peers.
For 2:
If you send them to a paper wallet and never connect to the btc network through a client running on your computer, then no, your IP can't be discovered. But, the only way to retrieve them from the paper wallet is to import it into an digital wallet of some kind, which, when you connect that digital wallet to the network to spend them, will identify you.

Also, see this: http://bitcoin.stackexchange.com/questions/193/how-do-i-see-the-ip-address-of-a-bitcoin-transaction?rq=1

As soon as you start the Bitcoin-Qt you connect to many networks because it is peer-to-peer network and people connect to your computer as well so yes your IP is out there on the internet whether you do any transaction or not.

Thank you Khan Shakrukh. But is there any records of those connections (not transactions) ? If so how could i have access to those records ?


text:
Can Lightning work without the "network" part?
Let's imagine a minimal version of the Lightning network with a single "central" lightning node (say a service provider which we can call a Server) surrounded by thin clients (the actual users potentially simply using open-source client software on their phone).
The network part in this scenario is non-existant as communication simply happens between Users <-> Server. Obviously to pay anybody in this system both users have to use the same Server.
I would imagine then each User simply having a channel open with the Server and whenever users Alice & Bob need to make payments with each other they simply use their single open channel with Server, and Server adjusts the 2 channels accordingly to follow on the payment. (I imagine some issues here with the payment not being possible if the channels are not funded in the direction needed for the payment).
Alice & Bob then each get their confirmation instantly validated by their open-source thin client (hence no trust with Server is needed).
I know there's has been lots of research and complexity around the "network" part of Lightning (such as routing mechanisms, funding channels, knowledge & discovery of network typography etc.) hence I was curious whether a simpler Client<->Server approach as mentioned above would be an easier and more user-friendly implementation strategy for simpler use-cases (such as regular users using a non-trusted central server like somelightningnode.com).
Are there any downsides of this approach apart from the clear fact that in order to make payments users have to use (but not trust!) the same Server?

What you’ve described is just a subset of possible architectures that are currently capable of being created using payment channels (the lightning network). Yes, this sort of ‘server/client’ relationship could/does exist (though I’m not sure I would call it that, exactly), but it’s also possible for any of the nodes involved in it to open channels with other nodes on the network as well.

Are there any downsides of this approach apart from the clear fact that in order to make payments users have to use (but not trust!) the same Server?

Being required to use this server is the downside: lightning is otherwise a free and open network, which allows users to independently allocate their capital in ways which they find beneficial and efficient.
you’ve mentioned a ‘light client’, which implies a client that does not fully validate the network state. This leaves open some vulnerabilities, in that the ‘server’ could provide false information to light-clients, in a way which they could not easily detect. The specifics of this would depend on the implementation details, of course.
having a single ‘server’ is a critical risk to the network: if it goes offline or is hacked, etc, then this mini-lightning-network will be taken offline entirely. Compare this to a more distributed architecture, where losing any one node is of minimal effect on the ability of other nodes to interact with each other.

Indeed & I agree that a whole network is much more beneficial & fault-tolerant. On the other hand it might yield more complex implementations as we're seeing with slower user-mass adoption. In a Client-Server network topology what would the channels look like? For instance if I start a channel with the server of 1 btc then I can't receive money until I spend money (bi-directional). And would you know if any of these  lightning client-server models exist?


text:
Is there a list of bitcoin block explorers?
Right now I mainly use blockchain.info as my main explorer, but is there a list of other bitcoin blockchain explorers as of today (2017 March)?

This may be a good place to start?
https://en.bitcoin.it/wiki/Category:Block_chain_browsers


text:
How does a transaction using a Bitcoin payment code BIP 47 look like on the blockchain?
Having that payment code addresses are untracable, how does a transaction look like in a block explorer if someone sends a payment to a reusable payment code?

BIP47 transactions look like any other transactions as far as inputs/outputs & fees are concerned. There is no difference.
Payments are not sent to the payment code itself but rather to addresses generated by the shared secret of both the sender's payment code and the receiver's payment code.
The only recognisable trace on the blockchain is the notification transaction, of one payment code to another, which includes an OP_RETURN. Notification transactions are done once for a sender to a receiver to initialise the payment "channel" and also permit any future restore of the wallet directly from the blockchain (in the event of lost metadata, for example).
https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki
https://github.com/SamouraiDev/BIP47_RPC


text:
As the number of Public keys available in BlockChain increases, does it cause extra risks for private key's security?

Any bitcoin address eventually use its public key when spending its BTC. And as we all know, bitcoin address is produced from a public key by utilizing one way function. What is advantage of using bitcoin address ?
Does it make any address anonymous till spending BTCs ?
While the block-chain size increases over the time, there are lots of public keys available, and some fraudulent person maybe try to estimate private key by enabling brute-force method.
Does it make any disadvantage or cause extra risks the whole system ?

Any bitcoin address eventually use its public key when spending its BTC. And as we all know, bitcoin address is produced from a public key by utilizing one way function. What is advantage of using bitcoin address ?

This keeps the public key private until the spending of funds. This means you have a higher degree of privacy than you would if that public key was displayed on the blockchain the entire time.

Does it make any address anonymous till spending BTCs ?

The public key is not revealed until spending when using a P2SH/P2PKH/P2WPKH

While the block-chain size increases over the time, there are lots of
  public keys available, and some fraudulent person maybe try to
  estimate private key by enabling brute-force method. Does it make any
  disadvantage or cause extra risks the whole system ?

There would have to be some serious advances in quantum computing for this to be feasible. However, this is why we recommend you do not reuse public keys when accepting Bitcoin payments.
As a side note, a downside to ushing pay-to-pub-keyhash schemes is that is requires an extra 20 bytes (in the case of P2PKH) on the blockchain. This adds up over time.

"This means you have a higher degree of privacy than you would if that public key was displayed" How so? A public key hash is just as good an identifier as the public key itself.

@PieterWuille True, I guess I was thinking of privacy of the key pair.

Any bitcoin address eventually use its public key when spending its BTC. And as we all know, bitcoin address is produced from a public key by utilizing one way function. What is advantage of using bitcoin address ?

A bitcoin address is not technically broadcast and included in the blockchain database until it is funded. So spending is irrellevant, because it would become public the moment it is funded.
Simply put, it's not "live" until it is funded. It's just a place card, if you have the private key, any funds sent to that account can be later spent, and upon funding, it would be public, regardless of whether there have been outbound transaction.

Does it make any address anonymous till spending BTCs ?

Spending, or Receiving, broadcasts the address with any transaction made through nodes, which confirm the transaction as valid and not duplicate. For each block that is found where the transaction you made is included, given you have included a fee which the nodes accept as "fair", is called a confirmation.

While the block-chain size increases over the time, there are lots of public keys available, and some fraudulent person maybe try to estimate private key by enabling brute-force method. Does it make any disadvantage or cause extra risks the whole system ?

No. There is no way, currently, for anyone to brute-force an address's private key. There are statistics and charts, but if you used the worlds fastest super computer, you would need millions, millions of years. It simply, is not feasible. Quantum computing could change that, but the reality is, quantum computing is not even yet in its infancy. (Not that we know of). It is way off in the distance, if ever.
That said. The reason cracking a private key from a public key is "impossible", is this:
Think of your Private Key as the Question.
Your Public Key, is the Answer.
It is not the other way around.
So if your public key is 100 (Shortened for this example) you know the answer. That is public.
To crack, you need to now figure out the question.
Is the question What is 10x10?  Or 1x100? Or 101-1?
Simply, there are far too many possibilities, in terms of questions, to any "answer". Cracking, brute-force, I don't think so.

I don't get your first point. Is it possible that you're mixing up addresses and public keys?

authors: داود اسکندری


text:
Why miners try to produce big blocks i.e. try to put transaction in a block as many as possible?
Why miners try to produce big blocks? What if, does a miner deliberately produce a block with a single transaction (and a coinbase transaction of course) without considering the whole unconfirmed transactions, in order to gain the reduce of network latency advantage or for some other purpose?

Why miners try to produce big blocks?

Because transactions pay fees. The more transactions they include, the more fees can be collected. They prioritize transactions with higher feerate to maximize this.

What if, does a miner deliberately produce a block with a single transaction without considering the whole unconfirmed transactions, in order to gain the reduce of network latency advantage or some other purpose?

Some do that (though mostly because they just received a new block, and haven't had the time to construct a valid set of transactions on top).
In recent times, the argument for faster propagation also does not apply very much anymore. Techniques like Compact Blocks (BIP152), the Relay Network, and FIBRE can efficiently transmit blocks as long as they mostly consist of transactions that were seen before. This almost entirely removes the effect of size from the equation.

A miner would want to include a lot of transactions in a block in order to collect all of the transaction fees associated with the transactions.
However, as alluded to, miners don't have to include transactions in their blocks if they don't want to.
Additionally, a miner may choose to include transactions with transaction fees and exclude transactions without transaction fees (as users can choose whether or not to include a transaction fee in addition to the size of the transaction fee).


text:
Claiming my BTG from my BTC private key
I have a BTC private key, how do I get my BTG? I have tried a few methods and tutorials but none seem to be working.
And beside that, is there any working BTG explorer? All the ones I found seem to be buggy (including btgexp.com) and wont recognize my address.
EDIT: yes I had BTC on this address at the time of the split
EDIT 2: found a working explorer with https://bitinfocharts.com/bitcoin%20gold
EDIT 3: yes I have transferred all my BTC to another address, and I just want to get rid of my BTG now

Did you have any bitcoin balance on the adress of which the private key belongs to, on BTG snapshot block 491407

Did you try to use a BTG wallet and import the keys?

Also, have you transferred the BTC to another wallet? I strongly recommend this before importing the keys to avoid any of the scams that seem to be abundant in connection to Bitcoin Gold.

@DanielR, are you talking about Bitcoin Gold's Core Wallet?  It doesn't seem to support importing of private keys at the moment.  Referring to https://bitcoingold.org/downloads/

If you have an iOS device, you can follow these instructions which I discovered myself: https://medium.com/@SimonEast/how-to-sweep-bitcoin-gold-btg-from-a-paper-wallet-using-ios-86010fa208de

AFAIK there's one good wallet other than the reference client that can import the private key and make a transaction.
That's Coinomi, it can import the private key and does support BTG.
(When I wanted to dump and sell my BTG, Coinomi was great, although I needed to use the Android emulator Genymotion [because I don't have an android device])

Most of the tutorials I have found googling are using Coinomi and this did not work for me.
I have moved my BTC from the address and only have BTG left, if I try sweeping the private key from Coinomi, I keep getting the message "The private key does not contain any funds".

But it does contain BTG! I can see it on https://bitinfocharts.com/bitcoin%20gold/address/

Alleluia, this finally worked!!!

@Oliver It was what I expected. You're welcome! That green button next to my answer, please.

Solution:
First, confirm your BTG balance on https://bitinfocharts.com/bitcoin%20gold/address/

go to https://www.bitaddress.org "Wallet Details"
(optional) Download the site to use it locally offline, check the github code to confirm it does not do anything harmful
put your BTC private key and press View Details
Install Coinomi
Create a new wallet and add BTG, then choose Sweep Wallet
Swipe the QR Code "Private Key WIF 51 characters base58, starts with
a '5'

DONE!!!
Always try first with a low value address, dont trust anyone when playing with private keys
EDIT 1: added step BTG explorer
EDIT 2: changed step 2 (optional)

To check the BTCG balance, I can use my BTC public key?

What date did the airdrop happen on?

@levi The airdrop happened on 1 Aug. No, you can't use the BTC public key, but the private keys are the same. Import your private keys to Coinomi and it'll show you your balance and addresses.

Beware, you should not upload your private key to anywhere. Never!

NEVER EVER give your private keys to some random site found on internet!


text:
thin-client remote node lying through omission
is there a way for a non-full node (ie a node which does not contain the full blockchain) to know when it has received all transactions associated with an address? i understand that it is possible for a non-full node to tell if it has been fed an invalid transaction - the node can check that the transaction hash exists in the pruned merkle tree for the specified block, then compute the merkle root for that tree and check it exists in the block header. but i don't know of any checks to ensure that all transactions have been downloaded.
if transactions are not relayed by a malicious remote node then the target node will think it has less funds available than it really does.
i had thought that bloom filters might fix this problem, but i read in bip37:

Thus, a merkleblock message is a block header, plus a part of a merkle
  tree which can be used to extract identifying information for
  transactions that matched the filter and prove that the matching
  transaction data really did appear in the solved block. Clients can
  use this data to be sure that the remote node is not feeding them fake
  transactions that never appeared in a real block, although lying
  through omission is still possible.

so it seems bip37 does not attempt to solve this issue.

Peers who don't use the whole blockchain are relying on at least one of their peers to send them transaction data when a transaction satisfies the bloom filter that the SPV (simplified payment verification) node has set. As such, SPV nodes have to be careful about which peers they connect to, and that they have a variety of peers. I believe some implementations of SPV nodes only connect to a set of defined, or are at least configurable to only connect to a strict set of peers.
Read how the bitcoinj (SPV node implementation) creator describes its security here:

Because bitcoinj apps do not accept incoming connections, the peers you talk to are always randomly selected at startup (based on DNS seeds today). So it can be difficult for an attacker to control your connectivity like that. For this reason, the number of peers that have announced a transaction is exposed in the TransactionConfidence object and you can listen on that to learn when new peers have announced a transaction. Once most of your peers have announced, you can be fairly sure that the transaction is propagating its way across the network and is very likely to be valid.

interesting. if i understand it correctly, dns-seeds just pick randomly from the available client ip addresses? if so then i think a malicious network admin (eg at the isp level) could limit your connection down to only unreliable peers who then omit txs. its far fetched, i know, but still...


text:
How is a Ripple gateway different than a conventional bank?
Everything I've read so far suggests that a Ripple "gateway" is just like a bank. How is it different than a conventional bank?
Is it possible to have a bank of banks (central bank) in Ripple?

A Ripple gateway acts much like a bank. They compete based on trust, convenience, and cost. They hold other people's money. They promise to handle that money according to their customer's instructions.
One difference is that there's no formal barrier to entry to becoming a Ripple gateway. Someone can open a gateway anywhere in the world and have equal access to the Ripple network for transferring balances, exchanging currencies, and so on.
You can imagine a "central bank" setup on Ripple. One way the central bank could work would be for the central bank to guarantee the performance of gateways and ensure liquidity between them by committing to maintaining a 1-to-1 exchange between the balances of the gateway's it guarantees and its own balances.
Another way a central bank could work on Ripple is if the central bank is the sole currency issuer and manages the account people trust. This would allow a currency with a money supply managed by a central authority.
A bank could also maintain interest bearing deposit accounts on Ripple. A central bank could maintain such accounts for banks or gateways.

Can you explain if Ripple can handle money as exchanger is it possible to use network for other financial operations like assets accounting, loans, deposits, stock exchange etc?

@economicus: Ask a separate question. The short answer is yes, though it's not ready to do all of these today.

The one big difference is that banks are allowed to create money.
When you take a loan out of a bank, the bank's funds don't go down. Your account gets fresh new dollars that are not coming from some other acount. They are brand new. Only a gateway with a banking permit would be allowed to do this, but then it would technically be a bank.


text:
What are Ripple's weaknesses?
Bitcoin's vulnerabilities are well documented. Is there are similar document for Ripple?

fast (ten seconds) Is it average time to get consensus in the network? Will it grow?

These are Ripple's largest known weaknesses (not including weaknesses common to Ripple and Bitcoin):

Because the Ripple network can't move actual fiat currencies, balances in Ripple act like bank balances. If the bank somehow defaults on its obligation, people won't actually have the money they thought they had. This is not a big problem if you're just using Ripple to make payments, but it's a weakness if you're using Ripple as a store of value for fiat currencies. Your money is only as safe as the "bank" that holds it for you.
If some unified group were able to get control over a significant number of validators that other validators trusted, they could temporarily disable the Ripple network (by refusing to reach a consensus) until manual intervention by other validators removed them.
Ripple's internal mechanics are still largely untested. As happened with Bitcoin, problems may be discovered as people begin to heavily use the system. Ripple's scalability has only been tested in simulation.
While the hope is that gateways will be all close enough to equal that people will be able to just sum their balances to get a sensible total, it's possible that different redemption policies or perceived trustworthiness will result in some balances being "devalued". So you might deposit $10 at a gateway, get a "$10" balance in Ripple, but find that because your gateway is not considered reliable, nobody actually values that balance at $10.
People might get tricked into extending trust to entities that are untrustworthy. We are already seeing "you trust me and I'll trust you" type offers. People may not realize that the system will give them what they ask for, giving them balances they have no way to collect on. Essentially, Ripple simply records balances. The system can't force people to settle them outside the system.
The stability and possible future changes in the value of XRP is unknown. If XRP is usable as a bridging currency, that should make cross-currency payments cheaper. But there's no assurance that it will be.
Until the network is decentralized, OpenCoin is a single point of control and possible failure.

In exchange, Ripple provides a way to perform fast (ten seconds), cheap (less than a penny) cross-currency payments with no way to lose money unless someone you chose to trust defaults. Ripple provides decentralized exchanges between any number of currency pairs. Ripple provides a way to seamlessly federate payment systems so people who use one payment system can pay people who use another, even across currencies. Ripple's design requires no central authorities and OpenCoin is committed to making it an open source, decentralized payment network.

"Your money is only as safe as the 'bank' that holds it for you." This is funny, because I don't know if my money is safe with any of the "real" banks (example: Cyprus depositor tax). Thanks.

"There's no assurance that it will be." Is this because the design isn't complete, or that the implementation isn't complete, or that it hasn't been tested in the real world? XRP is supposed to work as a bridge currency (transaction fee) as per the design, right? Or am I missing what "bridge currency" means here?

@Manish: The need to rely on gateways, at least for the near term, is probably the biggest weakness. By "bridge currency" I mean one that you can use to exchange between unpopular currencies. If I hold XYZ and you want ABC, and these are both unpopular currencies, it may be hard to find a payment path. But if there are lots of offers of XRP for XYZ and ABC for XRP, then XRP can "bridge" the two currencies. You can also combine those two order books to get an "ABC/XYZ" synthetic order book to trade on.

If I understand correctly, USD could just as well be used as a bridge currency over the Ripple network (owing to USD's popularity), but XRP would be even more efficient because it's native to Ripple. "If XRP is usable as a bridging currency...." Why wouldn't it be usable? Any technical reason, or just a matter of people not accepting it?

@Manish: The problem with using USD as a bridge currency is that someone has to hold that USD. Say XYZ is big in Poland where USD is handled largely by a Polish bank while ABC is used in Slovenia where some other USD gateway is popular. Now you need intermediaries between those USD exchanges. There's only one XRP. There's no technical reason inside the Ripple system why XRP wouldn't be used, it's a matter of whether it's suitable for that purpose which would require things like price stability and low risk.

In 2019 several exchanges suffered an attack called 'ripple partial payment exploit'.
It uses an integral part of the ripple network (partial payments) in conjunction with sloppy implementation by exchanges to defraud large amounts of money(in crypto) from those exchanges.
The largest known victim of this exploit is the beaxy exchange that got affected by some $570000 USD worth of cryptocurrency drained out of their wallets.
https://finance.yahoo.com/news/beaxy-exchange-likely-lost-570-142053125.html


text:
What are the pros and cons of Ripple's consensus as compared with Bitcoin's proof-of-work?
One of the major differences between Bitcoin and Ripple is how they process transactions. I can think of three ways in which Ripple's "consensus" scheme is superior to Bitcoin's proof-of-work:

Less energy-intensive
No 51% attack
Faster transactions

What are the other pros and cons of Ripple's consensus as compared with Bitcoin's proof-of-work?

The big advantage on the Bitcoin side is that its technology is now well-proven. Ripple's consensus system is the newcomer. Ripple was designed by people who had the benefit of seeing exactly what Bitcoin was doing and its strengths and weaknesses.
Ripple's consensus process can validate a transaction such that irreversibility is reasonably assured much more quickly. When a validator processes a transaction it signs the resulting final ledger. Those signatures are provided within seconds.
Bitcoin's proof of work scheme isn't path dependent. Ripple's consensus scheme is. This has advantages and disadvantages on both sides. Because proof of work is not path dependent, someone with sufficient hashing power can rewrite the past. However, the lack of path dependence also means that no state is required to determine the right chain. The rule for the winning chain is very simple -- the valid chain with the most work wins.
The biggest difference is how trust works. With a proof of work scheme, you must trust the majority of work. So long as the majority of hashing power remains in the hands of a large number of disjoint organizations, that's fine. However, if hashing power become consolidated, it's not clear what the fix would be.
With Ripple's consensus scheme, you choose who you want to reach a consensus with and declare the system unusable if you cannot. One advantage here is that you can reliably detect if you can't reach consensus. With Bitcoin, if the Internet splits in half and you're on the side with less hashing power, you can only infer it as a statistical probability. With Ripple, if you're not reaching consensus with people, you know it immediately.
Another advantage is that if you ever do have an attack or disruption, you have signed cryptographic proof showing who did it and what they did. You can simply stop trying to reach a consensus with them and then they would have to start over from scratch to attempt such an attack again. Because the effort required is so great and the payoff so low, it's much less likely people will try.
The disadvantage here is that UNLs (lists of who you want to reach consensus with) must be maintained and if your UNL is broken, you can fail in various ways that get worse the more broken your UNL is. The downside of being in control is that you can shoot yourself in the foot. The upside is that you can do something if someone else tries to shoot you in the head.
Bitcoin could fairly easily adopt some of the principles of Ripple's consensus scheme and gain many of these benefits. For example, mining pools could sign a statement indicating which chain they are building on. In the event of a network split, this would make it rapidly clear whether you were still on the same chain as those pools. In the event of a bug-induced chain split, you'd quickly know that something was wrong and would be able to stop relying on transactions automatically rather than having to wait for a manual warning to go out.

"Bitcoin could fairly easily adopt some of the principles of Ripple's consensus scheme...." Could proof-of-work be eliminated entirely in favor of consensus? This is especially interesting given how inefficient it is.

@Manish: Well yeah, in theory, but Bitcoin needs proof of work to distribute the currency anyway.

"(Ripple can not be attacked by 51% attack"
That statement is wrong i would believe? Ripple is run by one single entity; the ones who made ripple. Ripple is then technically NOT decentralized like bitcoin. Ripple would then be incredibly weak against external violence that could want to stop or damage their service. Like mean men with guns from a invading government. Invading government could be our own government gone rouge or a foreign government invading.
Bitcoin on the other hand is decentralized and extremely resillient towards any such force of external violence.
Ripple is also pre-mined, and all coins are in the hands of the ones who made ripple, unlike bitcoin which coins are rewarded randomly to the miners.
Ripple can then shortly put be equally (dis)trusted as much as any other already central-governmental issued fiat currency.

The question is about the consensus scheme. If someone ran Bitcoin only on one computer and closed it off from the world, that wouldn't be decentralized either.

@DavidSchwartz I'm not very sure about this, but to me it sounds like Ripple may actually be more decentralized than Bitcoin. In Bitcoin you have to trust "the network" (government), in Ripple you only have to trust specific nodes (family and friends). It's a lot more like how trust works in the real world.


text:
What's the point of trading BTC if you're limited in the things you can buy
If you're trying to make a profit by trading BTC... fine, I get it. What other reasons are there to trade BTC?

Why do people trade other currencies?

You're not limited. Any product or service you can imagine, you can buy with Bitcoin.

Ok I think I finally understand. Here's my best shot at it. Criticisms welcome: -There are two types of exchanges: peer2peer like Bitstamp and direct to consumer like Coinbase, which also provides a gateway for merchants. Merchants don't want to deal with volatility so they need Coinbases guarantee BTC to USD price and so are willing to pay 1% fees. On the other hand, Coinbase needs a peer2peer like Bitstamp so it can stock up on its own stock of BTCs. It's a supporting economy. Both exchanges are need at this point considering the volatility. Capitalism at its finest. Thoughts?

Going off my last post. Coinbase also needs peer2peer exchanges so it can sell its BTCs for USD. Overall, the exchanges support one another.

Without a doubt more and more merchants are accepting them. So I don't think thats a problem at this point.

@Cincinnatus: I didn't say "any store or service provider". I said "any product or service". Of course, that too may not be literally accurate, but is by and large true.

@Cincinnatus: Also, you're not supposed to "see" a store near you accept Bitcoin. You're supposed to go in and suggest to them to accept Bitcoin, and provide any needed help.

@Cincinnatus: 1. I wish all aspects of my life had "a problem" of the same sort Bitcoin adoption has. It's progressing at a very rapid pace. 2. Bitcoin is a financial revolution, not a mere "online technology". 3. Technological revolutions these days usually take ~10 years to be pervasive. 4. Being a commenter on bitcoin.stackexchange puts you far above the average user. And, if you lament on the lack of adoption, it only makes sense that you'll do something about it.

Well I guess there are three reasons I personally trade for.

Make a profit by buying BTC/fiat low and selling fiat/BTC high.
Potentially increasing the profitability of Bitcoin by increasing the coin volatility via trading.
Being a stakeholder in the currency of the 21st century.

Does this give you an idea of some of the motivations?

As the industry matures the general consumer will find it easier to use the underlying technology, Bitcoin. It might be as simple as swiping a card in the near future.
You can buy for speculative purposes or because you believe it will be useful in the future.

Well you might not be able to buy everything you want with it yet, but every day new merchants announce they accept bitcoin. Overstock and Expedia are just two of the biggest names I can recall right now. If the trend goes on like this, it won't take long for a lot of other big names to jump in. Once adoption grows larger the value is obviously going to go up. So you might want to do it as a long term investment too.


text:
Do forum or website exist where can buy things not usually sold with bitcoin?
Something like "wanted" classified advertisements is needed. Silk Road only sell offensive merchandise, no method to post wanted ads. Interested in purchase electronics, other legal unobjectionable products. Does website like this exist?

If you wish to have something specific bought for you, there are many people willing to facilitate this.  If it is simply a matter of placing an online order with your address, that is easy. If it needs to be re-shipped to you (e.g., seller doesn't ship to your country), that can be arranged as well.

The Marketplace on BitcoinTalk can be used.  Simply prefix your post's title with "[WTB]" which means "Want To Buy".
Discussion:

http://bitcointalk.org/index.php?topic=64607.0

Marketplace board:

http://bitcointalk.org/index.php?board=5.0

Also, the Bitcoin-otc marketplace can be used to place requests, if you are looking to buy.

http://bitcoin-otc.com/vieworderbook.php

Bitcoin classifieds
http://www.bitcoinclassifieds.net/
Music & other digital goods at
http://www.coindl.com

You can buy and sell songs and albums on Bitcoin at Liberty Music Store.
It is 100% legal and geared towards indie artists.


text:
Maximum number of op_codes in script
Is there any part of the Bitcoin protocol that established a limit on the maximum number of op_codes in a script.
Recently I have hit the limit for the bitcoin core client. In:
https://github.com/bitcoin/bitcoin/blob/ce56f5621a94dcc2159ebe57e43da727eab18e6c/src/script/interpreter.cpp
in line 276 you find:
   if (opcode > OP_16 && ++nOpCount > 201)
        return set_error(serror, SCRIPT_ERR_OP_COUNT);*

I interpret this line as saying that, outside standard type of transactions, there is a limit to 201 operations beside pushing a number from 0 to 16 to the stack.
Is this defined in any part of the protocol or discussed in any BIP?
I know there are limits for multiscript transactions:
https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki#520byte_limitation_on_serialized_script_size
and that the number of signatures should be limited to avoid certain attacks, but for lightweight operations (OP_ADD and the like) I cannot find any explanation on the limit and the exact 201 value.
P.S: I found the error when trying to spend the offending script. Curiously, I was allowed to send the transaction. It is when the client tries to verify the data for the next transaction when there is a problem.

Most if not all constants like that are not described, documented or otherwise discussed. For the most part the Bitcoin Core code is the reference which everything else follows, rather than the code trying to conform to any sort of standard. If it were hinged on a particular piece of documentation the network would need to be hard forked every time there was a new behavior found that didn't meet the specification.
201 operations is indeed the limit, and there is also a hard limit on the number of signature verifications that can occur in a block as well. Of all things in Bitcoin the script engine is probably the least well documented of all and has a number of oddities, partly due to its late inclusion.

It is when the client tries to verify the data for the next transaction when there is a problem.

You can make all sorts of completely invalid output scripts, because as you have found, there's no validity checks on them until they are spent. It is up to the author of non standard scripts to understand the system and not render their coins un-spendable. If you don't understand it, try these things out on testnet3 before you lose real money to them.

It's all testnet3 testing. In fact I managed to push the transaction to the mempool of a particular relay node: http://test.webbtc.com/mempool_tx/4114ff60040c60158e21bba9391af3798af49a56c9f918596b8419622bfa8fdb  They use a different Ruby implementation of Bitcoin. It seems, nevertheless, that most nodes use Bitcoin Core and the transaction will remain in a limbo for some time and then disappear. If it got relayed by Ruby clients, would the block be rejected by the network and create a fork or become part of the blockchain? Once in block is included there is less checking...

Your transaction is rejected by Bitcoin Core (-25), so Bitcoin Ruby accepting it would be erroneous. Your transaction is effectively nonsense and is trying to spend an OP_RETURN (unspendable) output so this isn't particularly surprising. Block validation is no less strict than transaction validation, in fact the validation is cached and reused in both.

@halftimepad re http://test.webbtc.com/mempool_tx/ .... What is that exactly? I knew of the relay or pushTx of the API, but I'm interested what you mean here. Are you pushing to this node via REST POST or BTC Core?

It's the output of http://webbtc.com/relay_tx .


text:
Why does hashing public keys not actually provide any quantum resistance?
In the discussions about taproot, it was mentioned that outputs will include the public key directly instead of hashing them. It is stated that, currently, hashing does not really provide quantum resistance. Why is that?

Related on crypto.SE

Although hashing a public key by itself does provide quantum resistance, this is really only when it is considered by itself in a vacuum. Unfortunately, public key hashes do not exist in a vacuum and there are many other things in Bitcoin that need to be considered.
Firstly, if public keys were hashed, the funds are only protected before they are spent. As soon as a P2PKH or P2WPKH output is spent, the public key is exposed. Whilst the transaction is unconfirmed, an attacker with a fast enough quantum computer could compute the private key and create a conflicting transaction which sends the funds to himself instead of the intended recipient.
Furthermore, if that attacker is a miner, they could do this with every single transaction and simply refuse to mine transactions that don't send the coins to himself.
While this is a problem, people often argue that it's better than someone just spending the Bitcoin outright because they have the public key from the blockchain. While that is true, there are an extremely large number of outputs with exposed public keys.
Over 5.5 Million Bitcoin are in outputs with exposed public keys, either because they are P2PK outputs, or because users are reusing addresses and thus public keys are exposed in other transactions. So if a quantum computer existed that could produce the private key for a public key in a reasonable amount of time, the attacker would be able to steal so much Bitcoin that they would decimate the Bitcoin economy and Bitcoin would become worthless.
So while your particular outputs may be protected by hashes, the value of those outputs would be 0 as millions of Bitcoin are stolen. All that the hashes really do is provide a false sense of security.
Then there are issues with tooling and wallet software the simply expose public keys in other ways than just in transactions and in the blockchain. No existing tools treat public keys as private information; there's no reason they should.
Many wallets send the parent extended public keys to a server so that the server can watch for transactions and send that data back to the client. Anyone who uses such a wallet, even temporarily, exposes their parent public key to a service provider. That provider could then compute the private keys to the public keys they have, derive all of the child keys, and steal all of the Bitcoin associated with anyone who has used their wallet.
Additional issues exist with complex scripts and contracts involving public keys. These scripts, such as multisigs, do not hash the public keys. Furthermore, these contracts typically exist because not all parties necessarily trust each other; one of them could be malicious. In such cases, a malicious participant in the contract would know the public keys involved (by virtue of knowing the script) and be able to steal the Bitcoin associated with those outputs. Existing public key hashes do not protect against this.
So overall, there are tons of ways that public keys are already exposed outside of transactions. These all would allow different kinds of attackers to steal millions of Bitcoin thereby causing the value of Bitcoin to go to 0, which renders any Bitcoin protected by public key hashes to be worthless anyways. Furthermore, users are probably exposing their public keys in unintended ways due to the software that they are using. So using public key hashes only serves to provide a false sense of security, while also increasing the size of transactions. In general, it is not worth the extra size.
Lastly, it is possible to do a transition to post quantum cryptography if it is found that a QC exists which can break ECDLP. If detected in time but still too late to do a proper upgrade, all use of signature algorithms relying on ECDLP (i.e. ECDSA and Schnorr) could be soft forked out thereby locking all coins. The coins could then be spent by providing a Zero Knowledge Proof of some non-exposed or quantum resistant information that indicates ownership of the private keys for the public key.
For example, users could provide a proof that they have the BIP 32 seed that was used to derive the private key for the given public key. Since it is a Zero-Knowledge Proof, the seed itself is not exposed (note that the seed is not part of a public-private keypair so there is no public component that is shared). Since most wallets use BIP 32, this should be sufficient. There may be other ways to prove ownership without risking coins that have not been thought of yet.
And of course, this all assumes that a quantum computer capable of computing the private key for a public key appears without the public being aware of the technology being close to existing. What is likely to happen is that the progression of quantum computers will be observed, and, at some point prior to them being powerful enough to break ECDLP, Bitcoin will soft fork in a Quantum resistant signature algorithm. Eventually, signatures relying on ECDLP will be removed. And all of that will occur before quantum computers truly becomes a threat. So in that scenario, hashing public keys provides no help anyways.

Note that all of the above is not just limited to quantum computers. It generally applies to any cryptographic break of ECDSA (or Schnorr).

Perhaps worth noting that considering one of the current Post Quantum signatures schemes (such as RFC 8391) for Bitcoin today would be extremely premature. Such signature schemes would greatly affect Bitcoin's usefulness, because they are huge in terms of size and/or slow and/or have footguns such as statefulness. This is still a very active research field with new schemes being proposed frequently and ongoing standardization efforts.

The mention of using a ZKP of a BIP32 seed to recover coins in a post-quantum world is interesting. Based on your reasoning, I'd agree hashing a pubkey doesn't provide meaningful protection for your BTC-stored wealth, but clearly there are advantages to more complex constructions for addresses (the BIP32 key-derivation function being more quantum-proof, in this case). So I think this prompts the question: what constructions are known to provide some level of safety from a quantum computer defeating the ECDLP?

I would like to add that Taproot will complicate the transition to a QC-secure signature scheme significantly as it exploits the linearity of Schnorr signatures, for which no QC-secure replacement is currently known.

I very much disagree on a couple points here. The idea that a miner could refuse to mine transactions that aren't sent to them is not well founded. Miners are incentivized to mine blocks with the highest total fees they can include. Unless the vast majority of miners had access to QC, there wouldn't be any string incentive for any of the miners to do this. Second of all, you assume that if 5.5 million bitcoins were stolen with a QC, that bitcoin would be "Decimated". The dollar has survived far more monetary inflation than that, so I think that is also quite unfounded.


text:
Why do websites such as satoshimines and bustabit generate new addresses every time?
Why a single address for each user not enough? Can't they just verify the incoming transactions?
If I want to mimic this practice, how can I generate unlimited addresses, from which transactions can be sent and received?
I am searching for an alternative to the Blockchain APIs...

That's the way it's supposed to be in Bitcoin. Address reuse is very bad for privacy and security.

There are privacy advantages of always generating a new address.
You can easily accomplish this with the use of HD wallets.


text:
What is the age of the youngest known Bitcoin developer?
What is the youngest age of someone known to have submitted a Pull Request to Bitcoin Core?

Matt Corallo (https://github.com/TheBlueMatt) was 18 when he started contributing to Bitcoin Core (back then just called Bitcoin).
At that age, he added support for UPnP, wrote the first dynamic DNS seeder, improved the build system, introduced wallet encryption, added debian package building, and fixed various bugs.

https://github.com/whitj00
Whit Jackson, 15 is the youngest I can find. Github does not list the ages of PR authors:)
http://www.coindesk.com/15-year-old-developer-ethereum-whit-jackson/
edit: I am not sure of his exact birthday. He may have been 14 when submitting this PR for bitcoin.org:
https://github.com/whitj00/bitcoin.org/commit/b3ef809c7c63c9ededa4f4ad40ef5ff314434fe8

Note question was about Bitcoin Core. I see Ethereum and bitcoin.org (the website) in the answer.

-1 As already implied by Jannes, it seems to me that Whit Jackson has not submitted a PR to Bitcoin Core. So, strictly spoken this answer doesn't address the question.

I marked the Pieter Wuille answer as correct because I technically did say core, however this answer was interesting too. It is nice to see developers get involved at such a young age!


text:
What security weaknesses result from using off chain solutions?
What type of security weaknesses are potentially created by using off chain solutions (such as the lightning network) for a portion of Bitcoin network traffic?

I don't know what bitcoin.se is like, but on Stack Overflow a question like this would be closed for being too broad. How do you define security? Which off-chain solutions for which traffic? There's an answer that assumes you're talking about using the Lightning network for payments, and security means being able to keep the money you think you've received.

TL;DR:
The security assumptions of using a LN channel for payments:

The blockchain is functioning well (confirming transactions quickly)
Channel nodes can keep secret data safe
There aren't any significant bugs in the software

With the Lightning network specifically, the security of the off-chain payment always depends on being able to take the transaction onto the real blockchain "if needed". When both parties cooperate, the number of on-chain transactions is minimized, but both parties rely on being able to cash out, using the real blockchain, if the other party stops cooperating or goes offline for an extended period of time. In addition, if the other party acts maliciously, you rely on being able to use the blockchain to punish their malicious actions.
One security risk lies here: if you cannot get transactions confirmed into the blockchain, you won't be able to get your money out of the channel, or to take counter measures when the other party tries to cheat you! So a well-functioning blockchain (confirming transactions quickly) is a definitely one security assumption of using the lightning network. So block crowding is one risk, since there won't be enough room for your transactions. Miners could also be bribed to not mine your transactions, although this is not a severe risk since it is likely that a different miner would confirm your transaction.

To understand some of the other security assumptions used in the lightning network, consider the following example. Suppose Alice has a payment channel open with Bob. First the channel balances read:
Channel Balance 1:
Alice: 0.5 BTC
Bob:   0.5 BTC

Then Alice makes a payment to Bob for 0.1 BTC, and the updated channel balances read:
Channel Balance 2:
Alice: 0.4 BTC
Bob:   0.6 BTC

But Alice decides she wants to try to cheat Bob! She tries to broadcast the transaction for Channel Balance 1, in which she gets 0.5 BTC, which is more favorable to her than her balance in Channel Balance 2, just 0.4 BTC. What's to stop her from doing this?
First, there is a waiting period before she can actually spend the funds from her 0.5 BTC output in Channel Balance 1 (technically the wait period applies to Channel Balance 2 as well). This wait period exists to give Bob sufficient time to notice that Alice has closed out the channel, and possibly take action if Alice has broadcasted an old version of the channel. In this case, since Alice closed out the channel with an older version of the channel state, Bob can actually take all of the funds in Alice's 0.5 BTC output! Hence, Alice is disincentivized from broadcasting old versions of the channel state.
The problem is that if Bob can't get his transaction that took the 0.5 BTC from Alice into the blockchain, then the wait period will end and Alice will have the opportunity to take the 0.5 BTC, successfully stealing 0.1 BTC (because she should only be allowed to take 0.4). So Bob depends on being able to take counter measures against Alice in the real blockchain before a wait period ends if Alice tries to broadcast an older version of the channel state.
(Note that this wait period also applies to Bob if he needs to get funds out of the channel without the help of Alice. Even if he broadcasts the most recent state of the channel, he has to wait. While this wait period may be inconvenient for Bob, Alice also has to abide by the wait period, which is what gives Bob a chance to take all of the funds in the channel if Alice tries to broadcast an old version of the channel. If things go as planned, though, and no one goes offline, then Alice and Bob can agree to make a new transaction to close the channel, where neither one has to wait to spend their funds.)

There is also a data security risk. Proving to the other channel party that you will not try to broadcast previous versions of the channel balance state involves giving the other channel party a bit of secret information, typically the preimage of a hash. Usually you only reveal this data to your channel counter-party when you update the state of the channel and receive a new guarantee of payment (just with a different balance). After you receive the new payment, you can reveal the secret information that invalidates the previous payment by giving them the ability to steal the funds from that old channel state if you try to broadcast it.
But if the secret data associated with the current state of the channel is revealed or stolen before you get a separate payment guarantee transaction, then effectively all of your transactions have been revoked and your channel counter-party can steal all the funds from any channel transaction you broadcast! So, the security of a LN payment channel depends on being able to keep data safe.

Another risk is simply bugs in software. If your software doesn't automatically handle all the edge cases of broadcasting the right transaction at the right time, and your counter party discovers that, they can take advantage of it and steal funds from the channel.

Couldn't you theoretically launch a successful attack on the lightning network just by having your node prefer LN transactions (since they're chained between many parties) which result in you gaining funds (e.g. which transfer to other parties) then favoring funds which result in losing funds (e.g. withdrawing from other parties) then waiting on the node to disconnect from the network (e.g. power outages, ISP failures, etc - that stuff happens all the time and if you have enough open LN connections you're bound to hit on a large number of them) before broadcasting an old state?

The submitter of the penalty transaction chooses the transaction fee, and it should always be possible to chose a higher transaction fee for the penalty transaction as for the fraudulent old commitment transaction, and theoretically both or none of the transactions should go through.  Ok, so Alice knows a miner and sneaked in that transaction ... but Bob can also get the penalty transaction in that way, some mining pool has paid services for prioritizing transactions.

I think one of the biggest risks is that there could exist an issue with the two way pegging mechanism. Such a failure could introduce issues where perhaps coins are unable to be retrieved from the sidechain and returned to the bitcoin blockchain. There is also the risk of an unknown network attack on the lightning network, perhaps a ddos attack against validator nodes that would render transactions unable to be processed on the off chain network. There could be others as well.

You're not saying this explicitly, but just to clarify if anyone besides me feels that it is implied: Lightning network is not a sidechain.

A sidechain is also not an off-chain solution. It is a means for experimenting with new blockchain technology without needing to introduce a new currency. But there is still a chain, and it has problems similar to that of the main chain.


text:
Security of Bitcoind
Due to recent reports of theft activities by hackers, is cyber security is an on-going concern for Bitcoin and are active measures being taken to improve security?

This question is very broad.  Are you asking about security for the Bitcoin protocol (e.g., different cryptography used)?  For the Bitcoin-Qt/bitocind software?  For users of hosted (shared) EWallets?  For uesrs of hybrid EWallets?   For hosted (shared) wallet providers?  etc.

You should always be aware of scam/hacks/thefts. Millions of dollars is stolen from 'regular' netbanks every year, so this is not really a "bitcoin-only" problem.
Bitcoin is based on crypto, so use this to protect your wallet. You can secure bitcoins way better than any other currency, but if your storing large amount of bitcoins in a unencryptet 'hot' wallet on a unsecure server, then your begging some hackers to steal your bitcoins.
You can find a lot of tips about securing your wallet here: https://en.bitcoin.it/wiki/Securing_your_wallet
But heres also some simple tips:

Encrypt your wallet (the build-in encryption is (almost) unbreakable as long as you choose a strong passphrases)
Never store all your bitcoins in a 'hot wallet' (unless your going to spend them all at once)
Make sure to take backups, and store them securely offline! (bitcoin-qt has a build-in key pool).
And make sure to keep your computer clean for malware

I would add to this to disable the RPC interface when not in use.


text:
How do you determine how much money an address has?
If you get an address, and have payments sent to you, how are people able to determine how much money you have? What steps do they do to figure this out?

Bitcoin's ledger system is publicly visible, but these are pseudonymous payments thus the level of privacy you wish to maintain is up to you.
A charitable organization, for instance, may want the transparency that using a static Bitcoin address provides (this is a concept affiliated with triple-entry accounting).
But an individual might not. Therefore, the default manner that bitcoin operates is to provide a obtain Bitcoin address for each transaction.
Also, if an individual is using a hosted (shared) EWallet, the Bitcoin address is simply used solely by the EWallet provider to know how much to credit an EWallet account -- so the balance shown by the blockchain has no relevance with the balance that shows for the user's EWallet account.
There are methods to try to make conclusions from looking at the flow of funds, but that is an imprecise tactic.  It might yield some info though and efforts are underway to share this information.

They don't.
You can have as many addresses as you like, and there is little anyone can do to track them all to you.
This means that usually people can know how much money a single address has, but that's pointless, since you can have multiple addresses.

"can know how much money a single address has, but that's pointless, since you can have multiple addresses." And since multiple people can share addresses (happens with wallet services).


text:
How is all this bitcoin theft happening?
When reading many stories about bitcoin theft, what is the usual gist? Dont most of these hackers get digital wallets that are encrypted? How do they make use of it, crack it...or its not encrypted at all?

Bitcoin-related thefts seem get a lot of attention compare to the much more common banking-related or payment service theft.  http://mashable.com/2012/10/24/barnes-noble-pin-pad-hack/

I would NEVER trust an app to split my secrets. Only use an open source library, and make sure you download the code and run it yourself on a computer that's disconnected from the internet (ideally never been connected to the internet). Try this python implementation: https://github.com/halfmoonlabs/secretsharing.

There are many ways theft can occur.
Even though the cases where hackers have stolen from exchanges or from individuals, in terms of the number of bitcoins lost that amount is chump change compared to the amount of coins lost to scammers such as PirateAt40 and other scams, including loans not being repaid or currency trades that go bad.
But as far as bitcoins lost to hackings, yes -- the thefts have been due to poor security practices being implemented by exchange operators and other businesses where an attacker takes advantage of that to steal funds.
The list of the top thefts in which these hackings includes some of the details for various incidents.
Security is difficult and expensive, and Bitcoin startups generally don't have the revenue and profits sufficient to attract the capital that would allow top-notch security to be implemented.  As a result, they become juicy targets for the attackers.
Even following the recommendations for securing online services does not ensure that there is no risk of theft, but most losses from theft thus far were because those recommendations weren't followed.
As far as the term "cracking" ... that generally refers to discovering passwords.  In June 2011 when an attacker obtained the list of accounts and password hashes from Mt. Gox, cracking was able to discover passwords for many accounts due to there having been poor security on the password hashing method implemented by Mt. Gox at the time.  Most Bitcoin-related service operators are smarter than that but that incident has helped any that weren't to become a little more aware of proper password security methods (e.g., BCrypt).
Password cracking might also be used by an attacker to gain access to a system which which may hold coins in an unecrypted wallet, or that breach may lead to credential that provide access to additional systems which hold coins in an unencrypted wallet.
The reason hackers are successful when compromising these server systems used by exchanges and other bitcoin businesses is because if software needs the ability to send outgoing payments then the attacker who has compromised the system then gains that same capability.  Even if the wallet is encrypted, the software would use the passphrase to unencrypt it so either the Bitcoin client is responding to requests after the passphrase has already been provided or the passphrase is avaialble to the software to make such requests.  And thus if that system is compromised there is no protection possible for those coins in the wallet on that system.
For this reason, any exchange or bitcoin business using hosting for their systems where the hosting service has any access to the hosted service whatsoever, those coins are at risk.  But most Bitcoin businesses are not at the scale necessary to justify proper security at data centers (e.g., using their own hardware colocated in locked cages in highly secure facilities).
Even with that, that is just the security for the hot wallet containing a fraction of the service's bitcoins needed for daily operations.  Security for the offline wallet might involve using paper wallets stored in bank vaults, or access protected with Shamir's Secret Sharing method even.
Much more common than breaches of security at Bitcoin exchanges and services are compromises of individual EWallet accounts at these online services.   This often happens when an individual shares a username and password for their exchange account with another service.  For instance, after the Mt. Gox passwords were leaked, other exchanges went on lockdown because so many accountholders had common login credentials on both services.  A protection against that is for the exchange to offer multi-factor authentication.
Individual users of the Bitcoin.org client can protect their wallets with passphrase encryption.  This still leaves them vulnerable to a replay attack should their system be compromised with a keylogger or similar malware.  For this reason, offline/cold wallet and "air gap" systems are recommended when the amount of bitcoins held are significant.  A similar recommendation exists for online banking, so compromised systems aren't specific to Bitcoin users.

Shamir Secret Sharing is great. If you're looking for a straightforward, easy-to-read python implementation, I'd check out secretsharing: https://github.com/halfmoonlabs/secretsharing.


text:
How can I use the blockchain API?
The blockchain is not designed in a way where you can easily get information correct? You have to know more than python basics and have good programming skills as their seems to be no API, and no methods of just querying the data to get basic stats such as "latest transaction" or "biggest transaction ever"....

Actually, the BlochChain API is pretty good and Ben Reeves has done a nice work implementing it. And for the most part, for free. You only have to know how to send HTTP requests from your code, and parse the Json your app receives. If you think his API is not complete or unworking, do it yourself and make him competition ;-)
An API is designed for programmers, not simple users. What do you want to do exactly?


text:
Should I validate transactions using the rules in BIP62?
BIP62 introduces a number of rules to prevent transaction malleability. However many transactions already in the blockchain fail these tests. Is BIP62 currently being used to filter transactions from entering the blockchain? If not then are there any plans by the core development team to use BIP62 like this?

Yes, you should.
BIP62 is currently not being pursued as a consensus rule on the network.
However, all its rules (including the ones that are only applied to new style transactions according to BIP62, specifically the lower-S rule) - are currently being enforced as a standardness rule since Bitcoin Core 0.11.1 and 0.10.3.
The reason for this is that at the time BIP62 was written, requiring lower-S was not feasible due to the large amount of wallets that were still creating high-S signatures. In recent times, a large fraction of them switched to lower-S, making it viable to just unconditionally apply that rule. If a significant amount of network nodes (and specifically, miners) upgrade to versions that enforce this, wallets that do not enforce lower-S will gradually stop working and need upgrading.
If that process completes and we end up in a state where near-0% of blocks still contain high-S signatures, people may want to propose unconditionally applying it as a consensus rule.

are the rules only mandatory when a transaction has version 3? i'm trying to validate the blockchain and some of the version 1 transactions fail the bip62 criteria, so i want to know when i should use them.

Version 3 transactions do not exist. Just read BIP62 as if it said "apply all these rules to all transactions". BIP62 only proposing them on new transactions because at the time it was unreasonable to apply to all of them for reasons explained above.

And in the blockchain BIP62 does not exist either. It is not a consensus rule. It's only enforced as a standardness rule so far.

cool. that's what i originally meant (i should have been more specific). in future how will i know whether to validate the blockchain against bip62. will the transaction version number be the determining factor?

nvm - i found the criteria in bip62 under block validity :)

As I said, BIP62 is outdated. It's a proposal. It does not describe the actual rules. If something like this ever becomes a consensus rule, it likely will not use new transaction versions, as it is no longer needed (see above).

How you will know what to validate? You don't need to. Soft fork consensus changes are backwards compatible. You're connecting to a full node anyway, right, so you won't accept invalid transactions?

Let us continue this discussion in chat.


text:
Can a transfer be done over postal mail?
Suppose I'm stuck in the middle of nowhere with no internet access and I want to make a payment to a certain Bitcoin address.
Is it possible to do a transfer via postal mail, and if so what information would I need to send?
Assume the following:

I have both the recipient's Bitcoin address and my (the sender's) own private key(s) memorized or written down on a piece of paper.
The person who receives the mail (my agent) has access to the Bitcoin network and will act on my behalf.
The mail is delivered securely (i.e. no chance of theft)

What information would I need to send in the mail?
Consider the following possibilities:

A)  Trust

I trust my agent to do the transfer to the given address (e.g. the agent is the recipient), but I can't trust my agent with my private key(s)
I trust my agent with all my information (private keys and all)
I do not trust my agent at all

B)  Access to a computer

I have access to a computer, so I can run any program/scripts that may be required for generating any signatures
I don't have access to a computer (and I'm not Rain Man)

"I have access to a computer" "I don't have access to a computer" Huh?

@NickODell, Manish is asking us to consider both those possibilities

@NickODell That's right, what are my options if (1) I have access to a computer, and what if (2) I don't.

If no one else answers this by the time I have time tomorrow, I'm all over this.

A1B1: Assuming you've prepared in advance, there are some nice offline wallet options.
A1B2: This one's tricky. I'm going to assume that you have access to a computer before running off into the woods, or what have you. I'm also going to assume that you know exactly the amount and address in advance.

Generate the transaction and sign it, but don't broadcast it (can be done with Bitcoin Armory)
Print out the transaction
When you want to make the transaction, mail the transaction to your agent.

A2B?: Easiest one. Just write down your private key and describe the transaction.
A3B?: Well, you're screwed, because the agent could just never make the transaction.

Thanks! About A3, so they couldn't just send the funds to another address (not the intended recipient) if I sent them the transaction as in A1B2? And I'm assuming that's because of the signature.

I suppose for A3 one option would be to build redundancy by having multiple agents, and multiple payments could be prevented by having only the exact amount available via that particular sender address (so only one of the transactions would go through).

@Manish "couldn't just send the funds to another address" "because of the signature" Yep. "multiple payments could be prevented" As long as you hand the exact same TX to every agent, you don't need to.

Great answer, you beat me to it! A1B2 is probably the most secure option of these.

@NickODell "As long as you hand the exact same TX to every agent ..." Hmm, how does that work? A transaction says "Send N bitcoins from X address to Y address (signed by X)" so what keeps it from going through multiple times as long as there's funds in X?

@NickODell Alright, I see my mistake. It's not "Send N bitcoins from X address to Y address (signed X)". Rather it's (roughly) "Send N bitcoins from output X to output Y,Y' (signed X)" where Y' is the change and X is empty after it's done.