Re: [Bitcoin-development] Adding callback hooks to the satoshi client
You might also want to check out libcoin. Its a fork of the satoshi client: https://github.com/ceptacle/libcoin Matt Eric Lombrozo wrote: Hey, guys. I've been writing a number of apps that require realtime event notifications, where the JSON-RPC API clearly doesn't suffice. There are two approaches I've been taking to this end: 1) Writing my own library for dealing with raw bitcoin structures and connecting to bitcoin nodes via the bitcoin protocol. 2) Making custom builds of the satoshi client putting callback hooks in key points. Neither of these two approaches is ideal. (1) involves a lot of code duplication, (2) involves patching the satoshi client source each time I grab a later version, with the everpresent risk of something breaking and the need to continue maintaining these patches. Moreover, unfortunately many of these key points happen to be in files like main.cpp which see frequent changes. I would like to propose adding these callback hooks to the main branch. I am willing to help locate these key points, reorganize the code to place these methods in separate source files, define a callback mechanism, and contribute source code. -Eric Lombrozo _ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Adding callback hooks to the satoshi client
I spent some time changing the internal bitcoin code to use callback hooks, but its far from complete (or even really usable from anything other than the code in the satoshi client itself, it doesnt even have any deregister methods!). As it sits now, it is likely to get more eyeballs and merged for 0.7. If you need additional specific callbacks, adding them would be cool, though I wouldn't recommend relying on the blockstore API to remain even remotely stable for the foreseeable future. https://github.com/bitcoin/bitcoin/pull/771 Matt On Wed, 2012-03-21 at 22:13 -0700, Eric Lombrozo wrote: > Hey, guys. > > I've been writing a number of apps that require realtime event > notifications, where the JSON-RPC API clearly doesn't suffice. > > There are two approaches I've been taking to this end: > > 1) Writing my own library for dealing with raw bitcoin structures and > connecting to bitcoin nodes via the bitcoin protocol. > 2) Making custom builds of the satoshi client putting callback hooks > in key points. > > Neither of these two approaches is ideal. (1) involves a lot of code > duplication, (2) involves patching the satoshi client source > each time I grab a later version, with the everpresent risk of > something breaking and the need to continue maintaining these patches. > Moreover, unfortunately many of these key points happen to be in files > like main.cpp which see frequent changes. > > I would like to propose adding these callback hooks to the main > branch. I am willing to help locate these key points, reorganize the > code > to place these methods in separate source files, define a callback > mechanism, and contribute source code. > > -Eric Lombrozo -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Adding callback hooks to the satoshi client
Hey, guys. I've been writing a number of apps that require realtime event notifications, where the JSON-RPC API clearly doesn't suffice. There are two approaches I've been taking to this end: 1) Writing my own library for dealing with raw bitcoin structures and connecting to bitcoin nodes via the bitcoin protocol. 2) Making custom builds of the satoshi client putting callback hooks in key points. Neither of these two approaches is ideal. (1) involves a lot of code duplication, (2) involves patching the satoshi client source each time I grab a later version, with the everpresent risk of something breaking and the need to continue maintaining these patches. Moreover, unfortunately many of these key points happen to be in files like main.cpp which see frequent changes. I would like to propose adding these callback hooks to the main branch. I am willing to help locate these key points, reorganize the code to place these methods in separate source files, define a callback mechanism, and contribute source code. -Eric Lombrozo -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal for a new opcode
On Wed, Mar 21, 2012 at 6:02 PM, Watson Ladd wrote: > -My protocol works, your's doesn't. It's not enough to have a mix, the > mix needs to be verifiable to avoid > one of the mixers inserting their own key and removing a key that > should be in there. That doesn't mean you can't make your protocol > work with some more magic, but magic is required. If the final step fails (someone says their address is missing) you challenge the mixes to disclose half of their correspondences. You can then prove which (if any) mixes defected. Why I didn't bother elaborating is ... I think you can even avoid the fancy protocol where you must take care to only disclose alternating halves at each mix because the addresses are throwaway: If the it fails in the final stage everyone publishes _everything_ and the cheater is instantly and provably identified and can be excluded from the next attempt which is then performed using totally new addresses and the disclosed addresses are never used. Care would need to be taken to avoid fake-failures (e.g. the exchange says 'it fails' triggering disclosure then sending anyways— but the participants could prove this cheating and stop using the exchange), I think there isn't much risk there if the participants are themselves the mixes. I need to think this through a bit more. [snip] > On a related note, private keys and signatures have better proofs of > knowledge then hashes. Has this been considered in the P2SH > conversation? There might be ways to use this to make even better > methods for enhancing anonymity. It's not something I thought about— In general the P2SH tends to be a superset of other schemes, e.g. you can do a signature to prove you access to a private key, then you can show someone a script using that key to show control of a P2SH address. There are lot of interesting things you can do with bitcoin if you can construct (potentially interactive) proofs for knowing the preimages of hashes. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Proposal for a new opcode
On Wed, Mar 21, 2012 at 3:54 PM, Gregory Maxwell wrote: > On Fri, Mar 2, 2012 at 2:57 PM, Watson Ladd wrote: >> Dear all, >> I am proposing a new opcode for the purposes of anonymous >> transactions. This new opcode enables scripts to be given proof that >> the receiver can carry out or has carried out a previous transaction. >> I'm currently working on a paper that discusses using this opcode for >> anonymous transactions. > > > Here is an alternative protocol: > > > N parties wish to purchase equal amounts of Bitcoin without the > exchange being able to link their future transactions, they each put > the relevant amount of gold/whatever up at the exchange. > > The exchange provides the exchanges public key, and the user provides > a public key for signing. Externally the N participants agree on a > collection of non-cooperating mixers (the mixers may actually just be > the participants themselves, independent third parties, etc). Each > participant generates a new bitcoin address, and encrypts it with the > the public keys of the the exchange and all the mixers using an > appropriate communicative homorophic scheme (or just a layers stack of > regular encryption keys). The participants then combine their > encrypted addresess into a block and hand it off to the mixing chain. > Each mixer randomizes the order and decrypts all the messages with its > key. > > At the end of the chain the exchange does the final decryption and > presents a list of addresses to the involved users. Users validate > that their address is in the set and sign the entire set. Once all > involved users have signed, the exchange pays. > > > This requires no changes to the Bitcoin system and could be trivially > implemented by anyone interested. It provides anonymity which is > strong so long as any one of the mixers is uncompromised. It has very > low overhead. It is not directly resistant to disruption, but if > participation in an identified round requires a key provided by the > exchange, abusive users can be detected and excluded. > > Have I explained this clearly enough? I could probably implement the > whole system it if its unclear. > > Can you contrast this with your proposal for me? Contrasts -My protocol works, your's doesn't. It's not enough to have a mix, the mix needs to be verifiable to avoid one of the mixers inserting their own key and removing a key that should be in there. That doesn't mean you can't make your protocol work with some more magic, but magic is required. -You need a lot of online computation: the recipients need to be involved with validating the mix. By contrast in mine you need to wait for enough people to get their bitcoins to avoid partitioning. But this might be a strength, not a weakness. -You avoid the problem of de-anonymizing through having the protocol run incompletely: if the permutation is correctly computed the transaction goes through. -You also avoid all the problems with modifications to the bitcoin clients and miners. It's definitely a good alternative, once you fix the problem in 1. On a related note, private keys and signatures have better proofs of knowledge then hashes. Has this been considered in the P2SH conversation? There might be ways to use this to make even better methods for enhancing anonymity. Sincerely, Watson Ladd -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: Proposal for a new opcode
On Fri, Mar 2, 2012 at 2:57 PM, Watson Ladd wrote: > Dear all, > I am proposing a new opcode for the purposes of anonymous > transactions. This new opcode enables scripts to be given proof that > the receiver can carry out or has carried out a previous transaction. > I'm currently working on a paper that discusses using this opcode for > anonymous transactions. Here is an alternative protocol: N parties wish to purchase equal amounts of Bitcoin without the exchange being able to link their future transactions, they each put the relevant amount of gold/whatever up at the exchange. The exchange provides the exchanges public key, and the user provides a public key for signing. Externally the N participants agree on a collection of non-cooperating mixers (the mixers may actually just be the participants themselves, independent third parties, etc). Each participant generates a new bitcoin address, and encrypts it with the the public keys of the the exchange and all the mixers using an appropriate communicative homorophic scheme (or just a layers stack of regular encryption keys). The participants then combine their encrypted addresess into a block and hand it off to the mixing chain. Each mixer randomizes the order and decrypts all the messages with its key. At the end of the chain the exchange does the final decryption and presents a list of addresses to the involved users. Users validate that their address is in the set and sign the entire set. Once all involved users have signed, the exchange pays. This requires no changes to the Bitcoin system and could be trivially implemented by anyone interested. It provides anonymity which is strong so long as any one of the mixers is uncompromised. It has very low overhead. It is not directly resistant to disruption, but if participation in an identified round requires a key provided by the exchange, abusive users can be detected and excluded. Have I explained this clearly enough? I could probably implement the whole system it if its unclear. Can you contrast this with your proposal for me? -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
