Hi,

I am attempting to design a piece of software which 1] uses a blockchain, 2] uses Bitcoin as a currency within this blockchain.

Unfortunately I have no crypto experience and low dev experience so the details of this are a little over my head. Does anyone know how a distributed piece of software might sign Bitcoin transactions? Is that possible somehow?

More details here (<2 pages): https://github.com/psztorc/Truthcoin/raw/master/docs/Development%20Plans/Design%20Question.pdf

I sketched up an idea where an application watches the longest valid chain of Blockchain 2 (B2), and (as new B2 blocks are discovered) takes the 'withdrawal requests' embedded in a "confirmed block" (say, 20 blocks beneath the current), and constructs/signs their Bitcoin transactions.

I have some questions about this:
* Can we derive (and use) private keys for an application such that they are never known to users? Can I prove that I don’t know/can’t use a private key?
* Can we hide private keys in an application that we widely distribute? To what extent could this application be open-source/trustworthy?
* Can we use randomness (chaotic inputs, or iterative randomness with block-hashes/nonce) to derive keys? Can such a piece of software copy itself or be copied?

* Is there a better way?

Thanks!

Hi everyone,

I work for the Yale Economics department (for a FED chairperson, in fact), and they very generously gave me 2 weeks of time off to make a conclusive effort on the project I’ve been working on in my free time for a few months, now. That good news aside, I’m feeling a little burnt out so I’m hoping to get some kind of support from the community or the project will probably stall out at this plateau.

Basically what I’ve done is built an incentive system which allows for the creation of Bitcoin Prediction Markets. As I mention in a first draft of my applications paper, these markets can be used for a number of purposes:

1.   Use the combined knowledge and intellectual ability of mankind to construct and refine the most accurate possible prediction of the future.
2.   End debates about the contentious issues of today, such as climate-change, heritability of IQ, effect of GMOs etc.
3.   Prevent lying from anyone (even politicians, industry leaders) about a target claim.
4.   Encourage and compensate whistleblowers.
5.   Provide ‘market advice’ on the relative impact of decisions on outcomes (“If we adopt X Fed policy, what effect on inflation can we expect?”).
6.   Provide insurance (buying and selling) opportunities for catastrophic global disasters, earthquakes, hurricane, etc.
7.   Allow tradable binary financial derivatives, for example on the BTC exchange rate, or the solvency of exchanges.
8.   Fun recreational gambling in real time, always at actuarially fair odds and low fees.
9.   Allows for the creation of ‘Trustless Dominant Assurance Contracts’ which allow financing of public goods such as lighthouse, roads, etc. with no counterparty risk.

Because the protocol (in theory) forces individuals to vote realistically on after-the-fact measurable outcomes, the protocol also has applications beyond prediction markets (as the Bitcoin blockchain has applications beyond transactions).
Here is the abstract to my paper:

 Abstract. Where Bitcoin allows for the decentralized exchange of value, this paper addresses the decentralized creation and administration of Prediction Markets (PMs). An alternative proof-of-work blockchain collects information on the creation and state of PMs, with the winning state of a market determined by a modified weighted-vote. An incentive mechanism attempts to guarantee a) that all voters vote honestly, and b) that PM-creators act as entrepreneurs, bearing the economic costs and benefits of the PMs they create. Bitcoin users can create PMs on any subject, or trade anonymously within any PM, and all PMs enjoy low fees and infinite market liquidity through a LMSR market maker. Scalability and customizability can be achieved via ‘branching’ (controlled-fork). The paper closes with a discussion of implementation details.

Hopefully there is enough interest to reach out to other collaborators (Bitcoin Foundation, Altcoin developers, etc.)
The entire project can ride on its own blockchain, or possibly even in the OP_RETURNs of the Bitcoin blockchain, no hard fork or any major change required.

I’ve avoided the final puzzle piece, which is how to have the protocol sign withdrawal transactions (for people to move their Bitcoin back into addresses they control). I provided 7 possible approaches, but even that was probably a waste of my time because I’m sure any professional dev would instantly know their favorite approach, and, (moreover) new approaches are constantly invented (example: Etherium was invented after I wrote the paper).
 
Thanks for reading!
-Paul

https://github.com/psztorc/Truthcoin/tree/master/docs

Like e-cash services, prediction market services have been unjustly terminated by those who misunderstand their economic costs and benefits. For the past 2 months I have been working on a decentralized prediction marketplace, which would allow users to create and trade in any prediction market they like with (only theoretically, I'm afraid) zero counter party risk.

My proof-of-concept code is almost done (although it is in R, I plan to rewrite in the more mainstream Python), but I make this post to announce that I have completed my first draft of the whitepaper: Truthcoin_1.pdf in the docs folder of my GitHib repo https://github.com/psztorc/Truthcoin .

Comments and Feedback are appreciated, particularly in the implementation section. I am not a computer scientist or cryptographer, the techniques I used in the protocol specification were all based on what I observed-to-work (Bitcoin, signing/encryption, block validation) and not based on anything I actually understand, so I feel that the input of the community could potentially be very helpful in bringing this project closer to implementation.

Subject: Masking the BTC transaction quantity (+anonymity) with 'bills'.
Cost: all users must change the default way they write transactions, recipient must use stealth addresses.

(This is a repost from somewhere....I thought I read about this idea in our forums here, or in the Zerocoin paper, but I couldn't find it and cant remember where it came from and no one seems to be talking about it. It interacts with Stealth addresses to become MUCH more effective).

Simply put, you change default transaction construction in order to exploit Stealth Addresses' ability to provide senders with multiple addresses, by breaking up your payment into addresses of standardized sizes. Probably powers of 2 are the best way to go .

So, if 2^x were the sizes (1,2,4,8,16...), to send 13 BTC to someone you would:
Request an address
prepare to send 8 BTC to that address (13-8=5 left over)
Request address #2
prepare to send 8 to address.1 and 4 to address.2 (5-4=1 left over)
Request address #3
prepare to send 8 to address#1, 4 to address#2, and 1 to address#3

Values below some cutoff ("change") can simply accumulate until they become the first 'bill'.

Of course, this does not itself mask the transaction (as you can still just add up the total amount spent), but it does allow users, if they wish, to construct separate 'masked' transactions, for example 3 payments of 8, 4, and 1, (or 8+1 and 4, or 4+1 and , separated in time and that will blend into the regular mass of transactions completely at the normal cost of a transaction fee per extra transaction.

This also makes it impossible to determine the change address(es) (as you would request several new addresses from yourself) or the change amount (now logically impossible to determine what it is) and even makes CoinJoin a little easier, as it standardizes the values it requires to coordinate.

Hello, I'm curious about something and could not find the answer.

Situation: "A" signs a 2 of 2 multisig transaction, sending to "B". It still needs to be also signed by a third person "C" to actually go through, but C doesn't know who A and B are, and is never told about this transaction.

1] Can C use the blockchain to find a broadcasted half-signed (signed only by A) transaction? Ie is a "find all mutisig transactions that pubkey X still need to sign with its private key" operation possible?

2] Can A write a transaction that has two outputs, one multisig 2 of (A, C) to (B), and another single-sig to C (containing a tiny amount) to aid in this purpose? C sees that he has received funds, goes to the originating address, and signs the yet-to-be fully signed multisig transactions.

Is it even possible to broadcast "half-signed transactions"?

Thank you!

Hello,

I started a great discussion over here: https://bitcointalk.org/index.php?topic=139443.0 about timestamping files with BTC. Please read my posts and share your thoughts:

A] You share my vision of BTC Timestamping, fully embrace the point about 'Verifiability' I raised on the second page, and, in fact, will push for its inclusion in Electrum and all clients.

B] You think its a great idea but aren't sure its worth the effort or will catch on (you're wrong!).

C] You have problems with the idea (please share them).


I have code to do this in Python, but its so simple that perhaps ThomasV/an established developer will just want to do this him/herself in ~15 minutes. Because Electrum doesnt require the blockchain, it is ideal for user-friendliness (ie a non Bitcoin user could download this software and use it to verify published timestamps).

This is a very simple feature but without standardization and ease-of-use (read: Mac/Windows GUI) there will be insufficient Verifiability...I am reaching out to the Armory community in a similar post.

What do you think?

[Please]

Hello,

I started a great discussion over here: https://bitcointalk.org/index.php?topic=139443.0 about timestamping files with BTC. Please read my posts and share your thoughts:

A] You share my vision of BTC Timestamping, fully embrace the point about 'Verifiability' I raised on the second page, and, in fact, will push for its inclusion in Armory and all clients.

B] You think its a great idea but aren't sure its worth the effort or will catch on (you're wrong!).

C] You have problems with the idea (please share them).


I have code to do this in Python, but its so simple that perhaps eipi will just want to do this himself in ~15 minutes. Armory's multiple wallets feature is already a major pro in the ultra-easy implementation of this, as it is essentially ImportPrivateKey(Hash(file)), but you dont want anything to happen to your existing wallet.

This is a very simple feature but without standardization and ease-of-use (read: Windows GUI) there will be insufficient Verifiability...I am reaching out to the Electrum community as well!

What do you think?

[Personally, I envision a drop down selection in the client GUI]

Many people, including myself, have a vision of using BTC to make an unalterable timestamp of a file.

________
Background for those unaware:
Unfakeable timestamping is easy to do with Bitcoin because you can just use a SHA256 of any file as a privatekey, import it, and then send BTC to it and back. The fact that you sent BTC to, and then from, the file's associated Bitcoin-key-and-address proves that you had access to the file at a certain time (the time of the transactions).

The low-tech, quick-and-dirty way is to:
1] SHA256 a file containing the contract/great ideas you want to take credit for later.
23e039cf88c6f2fe89415b938d62245af3f339ccf734d8d0c939422c7e4bb8b8

2] Hit up brainwallet.org
2.1] Convert Hex (hash) to Base58 using the convert tab of brainwallet.
5J65yxHPWGfNrXatL8gKwqhFJh9tAXKPmAxYHxFk8b9ACsxd9jS
2.2] Import this as a Private Key on the Generator tab of brainwallet...you will get an associated public key and Bitcoin Address.
1LHnjmyNPDmb9PopeBNrnhNTGVkVkhTGgY

3] Send some BTC to that address using your client.
4] Use brainwallet (transactions tab) to send that money back to your main wallet (the temp wallet created in 2.2 will not be secure when you release the file with all your great ideas, as anyone can hash it).

5] Wait patiently at http://blockexplorer.com/q/addressfirstseen/ for your BTC to show up in the network. Unfortunately this functionality has yet to be incorporated into open-source Abe (and I failed to replicate it myself).
http://blockexplorer.com/q/addressfirstseen/1LHnjmyNPDmb9PopeBNrnhNTGVkVkhTGgY
2013-01-28 05:30:09
________
Previous discussion of this:
https://bitcointalk.org/index.php?topic=52715.20
https://www.strongcoin.com/en/blog/using_the_blockchain_as_a_trusted_timestamping_service
Goblin invented a version of this, but I could not get it to work (sorry!): https://github.com/goblin/chronobit
Someone wrote a paper about this and related ideas: http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=11&cad=rja&ved=0CC8QFjAAOAo&url=http%3A%2F%2Feprint.iacr.org%2F2011%2F677.pdf&ei=OwIGUcqoCarD0AHDy4D4Bg&usg=AFQjCNE53BUwzCopGFXB9lX7F4tOYEpyzw&bvm=bv.41524429,d.dmQ
________


Personally, I envision this as something that would actually make a great core feature. Much in the way that gold is used in industry/jewelry (in addition to being a store of value and medium of exchange) Bitcoins can be used to timestamp files in an unalterable way for ~free (and used for sending international transfers for ~free, unfreezable assets, brain-storage, etc), in addition to being a store of value and medium of exchange.

Personally, I envision a drop down selection in the client GUI (for example **File > Timestamp File**) that just asks you for the path of the file. Easy to use, mainstream for everyone! Likely also a **File > Get File Time** to verify that a file was stamped. Obviously for this to happen there would need to be widespread community support.

Having millions of copies of proof of existance/ownership is way cooler than jewelry! Am I wrong? There are other minor benefits, like responding to people who say that "Bitcoins are inherently worthless / not 'backed' by anything" and helping to explain the sheer quantity of BTC addresses (at minimum 1 per possible MS Word document you could ever create) to people who worry about collisions or make similar arguments.

Your thoughts?

Note: I tried to code all of this myself but I ran into two snags, replicating /addressfirstseen/ and getting a ecdsa public key from a given private key (where is brainwallet.org getting 'G' to do the multiplication???). Im sure the core developers could do the whole thing in like 15 minutes if they wanted to, though, even if it needs to rely on blockexplorer.com's /addressfirstseen/  for now.

Dear Technical Users,

Can we simply require that more decimal points be added if the block reward were to drop to 0 (or a few years in advance of), so instead reward eventually becomes .5 satoshi (0.000 000 005 BTC, at this point divisible to 9 digits), then .25 satoshi (BTC divisible to 10 digits), .125 (BTC divisible to 11 digits), etc?

http://xkcd.com/994/ (Happy Holidays everyone)

I know 'adding decimal places' is a hard fork, but if we forked it this way (to constantly expand on schedule) we might *only* need to fork it once.


...
Now tell me all about how you hate this idea.

[sticky the key recurring topics ('price manipulation', 'tainted bitcoins', 'developers change source code', 'quantum computing', etc)]

Frequently, people have been complaining about a threat to Bitcoin without first reading existing posts/documentation about it. Responding to these posts is wasteful and annoying, but ignoring them makes it appear (to outsiders) that the treat is legitimate.

I propose a new forum category to catch these posts (possibly under 'Bitcoin Discussion'). We then sticky the key recurring topics ('price manipulation', 'tainted bitcoins', 'developers change source code', 'quantum computing', etc) so people know where to find the information they want (and don't make redundant and misleading new posts).

I know we have wiki pages for this, but sadly it does not stop lazy users from flooding the forum with garbage (garbage that falsely makes BTC look vulnerable). There are just too many posts to look through...I think this organization can help.

tl;dr Just like the 'deflation' sticky in the Econ section of the forums, but a catch-all category for all annoyingly recurring topics.

[it worked]

Hello CompSci/Math people,

Part 1

I just went here http://shakespeare.mit.edu/hamlet/full.html to grab the entire text of the play Hamlet, and pasted it into the 'Passphrase' box of brainwallet...and...it worked.

By this I mean: it fit the entire text into the little box, and generated the keys/address in about 1 second.

I did not expect this to happen...does anyone know exactly how much text/what kinds of text this thing can eat before it breaks?

Part 2

Can I achieve secure entropy with:

1) Pick stable website
2) (Optionally) find/replace all 'X' with 'Y'
3) Copy text / html source / whatever into brainwallet passphrase.

Assuming the website/text would not change, this would be secure(?) and memorable (basically only 1 or 2 things to remember)...what's the catch I am missing?

Part 3

Ultimately, why not allow clients to import any file, not just text, to generate keys. Given cloud computing / backups of huge filesystems, I could then choose one tiny pdf/mp3/doc stashed somewhere in my library of files...attacker, even after breaking into my actual file system (which would already be pretty bad), still wouldnt know which file to use, especially in the mp3 case where the files are accessed often (and have emotional/memorable significance to users but not attackers), and can be reproduced from (for example) youtube videos or something.

...sorry if this was discussed before, I did not see it.