Locate the section for your github remote in the .git/config file. It looks like this:
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = [email protected]:joyent/node.git
Now add the line fetch = +refs/pull/*/head:refs/remotes/origin/pr/* to this section. Obviously, change the github url to match your project's URL. It ends up looking like this:
Evan (@emschwartz) came up with this idea we sometimes refer to as Fishchain. The idea is that you can request a packet of data by broadcasting a payment where the condition is the hash of that data.
Not sure if this new or not, but I just noticed that the Fishchain idea works not just for message retrieval bounties as stated above, but message delivery bounties as well.
Imagine A wants to deliver a message m to B, but doesn't have a direct connection. C has a way to talk to both A and B, but doesn't want to relay a message for free. Neither A nor B trust C.
A could tell C: My buddy, B, will pay you 5 cents if you deliver my message to her.
C thinks that that is a fair price, so she first gets A to sign the hash of the message H(m). She then contacts B saying that she has a message for her whose hash is H(m) and presents A's signature over H(m). B promptly creates a transfer to C using H(m) as the condition.
| ➜ rust-libwally cat Cargo.toml | |
| [package] | |
| name = "rust-libwally" | |
| version = "0.1.0" | |
| authors = ["Riccardo Casatta <[email protected]>"] | |
| build = "build.rs" | |
| [dependencies] | |
| libc = "0.2" |
If timelocked outputs are used as fidelity bonds, there is some inevitable degradation in the anonymity of users of a system that requires such bonds. Part of this would be entirely unavoidable - in that when the utxo is spent, the CLTV nature of the scriptPubKey must be revealed, and in most scenarios this would probably watermark that the utxo was being used for a fidelity bond purpose. But what might be avoided is the tracing, or linking, of a particular utxo used repeatedly for the same purpose.
To make the issue clearer, consider the specific case of Joinmarket, and the recent proposal on fidelity bonds by Chris Belcher [1]. Here, the fidelity bond would be used to sign an ephemeral identity used on a message channel. The user, having committed funds to the bond, would perforce re-use that same bond every time he reconnects to the trading pit and so what is currently a completely ephemeral identity (it can be changed as often as
Near-stateless, fully parallelizable validation of the Bitcoin blockchain with hints about which outputs remain unspent. All other inputs/outputs are efficiently crossed off inside a single hash aggregate that only reaches zero if validation was successful and the hints were correct.
Validation is at the heart of Bitcoin. Any improvements in validation speed will have a direct impact on the scalability of the system, including everything that is built on top of it. For this reason improving validation performance may be one of the most important things we can do.
The generalized observation of SwiftSync is that if we have two sets (in this case the inputs and outputs), and we want to know the difference between these sets (the UTXO set), validating a given answer to this question (the hints) is significantly easier than calculating the answer itself. The novel part here (to my knowledge) is specifically how this can be applied to sets. It seems likely that this observation ca
