Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
On Thu, Feb 19, 2015 at 6:30 PM, Mike Hearn wrote: >> He didn't said "a project for all possible language bindings", just >> java bindings. Other languages' bindings would be separate projects. > > > Yes/no/sorta. > > Java/JNA bindings can be used from Python, Ruby, Javascript, PHP as well as > dialects of Haskell, Lisp, Smalltalk and a bunch of more obscure languages > like Scala, Kotlin, Ceylon, etc. > > It makes more sense to talk about bindings to particular runtimes these > days, rather than particular languages. Oh, I didn't knew that. Thanks for the clarification. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
I strongly suggest you take a look at swig for doing this. It's very straightforward generating bindings in an automated fashion with it. http://www.swig.org/ You could probably have it done in one or two days with Swig. Once you do the Java bindings with it, it'll be a few adjustments and you'll have bindings for other languages as well. http://twitter.com/gubatron On Thu, Feb 19, 2015 at 4:43 PM, Sean Gilligan wrote: > On 2/19/15 9:30 AM, Mike Hearn wrote: > > > > Java/JNA bindings can be used from Python, Ruby, Javascript, PHP as > > well as dialects of Haskell, Lisp, Smalltalk and a bunch of more > > obscure languages like Scala, Kotlin, Ceylon, etc. > > > > It makes more sense to talk about bindings to particular runtimes > > these days, rather than particular languages. > > I'm definitely interested in helping to create and test JVM bindings. > Where should such a project be launched? As a subproject of bitcoinj? > > > > > -- > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > > http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
On 2/19/15 9:30 AM, Mike Hearn wrote: > > Java/JNA bindings can be used from Python, Ruby, Javascript, PHP as > well as dialects of Haskell, Lisp, Smalltalk and a bunch of more > obscure languages like Scala, Kotlin, Ceylon, etc. > > It makes more sense to talk about bindings to particular runtimes > these days, rather than particular languages. I'm definitely interested in helping to create and test JVM bindings. Where should such a project be launched? As a subproject of bitcoinj? -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
> > He didn't said "a project for all possible language bindings", just > java bindings. Other languages' bindings would be separate projects. Yes/no/sorta. Java/JNA bindings can be used from Python, Ruby, Javascript, PHP as well as dialects of Haskell, Lisp, Smalltalk and a bunch of more obscure languages like Scala, Kotlin, Ceylon, etc. It makes more sense to talk about bindings to particular runtimes these days, rather than particular languages. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
On Thu, Feb 19, 2015 at 3:09 PM, Tamas Blummer wrote: > On Feb 19, 2015, at 3:03 PM, Bryan Bishop wrote: >> Second, I think that squeezing all possible language bindings into a project >> is also unproductive. > > The language binding would be an independent and separately hosted project > only using the C interface of the libconsensus library. He didn't said "a project for all possible language bindings", just java bindings. Other languages' bindings would be separate projects. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
On Feb 19, 2015, at 3:03 PM, Bryan Bishop wrote: > First, I strongly disagree with voting here for reasons that I hope others > will elaborate on. I meant voting by pledging on the lighthouse project, not here on the list. Sorry for not stating this explicitelly. > Second, I think that squeezing all possible language bindings into a project > is also unproductive. The language binding would be an independent and separately hosted project only using the C interface of the libconsensus library. Tamas Blummer signature.asc Description: Message signed with OpenPGP using GPGMail -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
On Wed, Feb 18, 2015 at 11:22 PM, Tamas Blummer wrote: > I launched a Lighthouse project to add Java Language Binding to lib > consensus. Let's turn the debate to a constructive vote. First, I strongly disagree with voting here for reasons that I hope others will elaborate on. Second, I think that squeezing all possible language bindings into a project is also unproductive. What is it that the webkit people did for this? I think they had gobject bindings, and then all of the languages have their own gobject bridge to take advantage of that. Naturally the downside here is that gobject means you have a gtk dependency. A similar solution would be interesting and worth exploring, though, especially if something similar without gtk exists. - Bryan http://heybryan.org/ 1 512 203 0507 -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] What's what with addr relaying?
Oh and I realised I stuffed up the subject and it talks about the addr relay but I actually answered my own question on the addr relaying, I had just miss interpreted one document I thought it was talking about subtracting 2 hours before relaying but I see we subtract 2 hours on receipt not relay because the if it hadn't been seen for 60 minutes previously it now becomes 3 hours and we use but don't relay makes sense. On Thursday, 19 February 2015, 22:33, Thy Shizzle wrote: Hi, plugging away at my C# Bitcoin node "Lego.NET" Thashiznets/Lego.NET now I am currently working on addr relaying. I am as we speak wiring up my DB in Azure, and ready to start plopping net_addrs in my DB, all good however I'm reading two different specification docs that seem to be wildly varying. I mean the first one here Developer Reference - Bitcoin didn't mention that version message now has the 4 byte checksum and no time in the net_addrs and I was getting reject malformed messages until I found the other document which informed me we now use the 4 byte checksum in version and no time in the net-addrs in version message. So I solved that and here is the other doco. I have found other variances like one document said that the heartbeat AND disconnect were 30 minutes, but then in the other document I read that Heartbeat is 30 minutes and disconnect is 90 minutes which seems far more sensible so I went with that and modified my code. Is there any other variations between these two spec docos that perhaps some of you devs know about that I need to look out for! Thanks! Shizzle. | | | | | | | | | | | Thashiznets/Lego.NETLego.NET - A C# full node for processing the Bitcoin block chain | | | | View on github.com | Preview by Yahoo | | | | | | | | | | | | | | | | Developer Reference - BitcoinBETA: This documentation has not been extensively reviewed by Bitcoin experts and so likely contains numerous errors. Please use the Issue and Edit links on the bot... | | | | View on bitcoin.org | Preview by Yahoo | | | | | | | | | | | | | | Satoshi Client Node Discovery - BitcoinContents 1 Overview 2 Handling Message "getaddr" 3 Discovery Methods 3.1 Local Client's External Address 3.2 Connect Callback Address 3.3 IRC Addresses 3.4 DNS Addresses | | | | View on en.bitcoin.it | Preview by Yahoo | | | | | -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] What's what with addr relaying?
Hi, plugging away at my C# Bitcoin node "Lego.NET" Thashiznets/Lego.NET now I am currently working on addr relaying. I am as we speak wiring up my DB in Azure, and ready to start plopping net_addrs in my DB, all good however I'm reading two different specification docs that seem to be wildly varying. I mean the first one here Developer Reference - Bitcoin didn't mention that version message now has the 4 byte checksum and no time in the net_addrs and I was getting reject malformed messages until I found the other document which informed me we now use the 4 byte checksum in version and no time in the net-addrs in version message. So I solved that and here is the other doco. I have found other variances like one document said that the heartbeat AND disconnect were 30 minutes, but then in the other document I read that Heartbeat is 30 minutes and disconnect is 90 minutes which seems far more sensible so I went with that and modified my code. Is there any other variations between these two spec docos that perhaps some of you devs know about that I need to look out for! Thanks! Shizzle. | | | | | | | | | | | Thashiznets/Lego.NETLego.NET - A C# full node for processing the Bitcoin block chain | | | | View on github.com | Preview by Yahoo | | | | | | | | | | | | | | | | Developer Reference - BitcoinBETA: This documentation has not been extensively reviewed by Bitcoin experts and so likely contains numerous errors. Please use the Issue and Edit links on the bot... | | | | View on bitcoin.org | Preview by Yahoo | | | | | | | | | | | | | | Satoshi Client Node Discovery - BitcoinContents 1 Overview 2 Handling Message "getaddr" 3 Discovery Methods 3.1 Local Client's External Address 3.2 Connect Callback Address 3.3 IRC Addresses 3.4 DNS Addresses | | | | View on en.bitcoin.it | Preview by Yahoo | | | | | -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
On Sun, Feb 15, 2015 at 11:40:24PM +0200, Adam Gibson wrote: > > > On 02/15/2015 11:25 PM, Troy Benjegerdes wrote: > > > > Most money/payment systems include some method to reverse or undo > > payments made in error. In these systems, the longer settlement > > times you mention below are a feature, not a bug, and give more > > time for a human to react to errors and system failures. > > > > Settlement has to be final somewhere. That is the whole point of it. > Transfer costs in current electronic payment systems are a direct > consequence of their non-finality. That's the point Satoshi was making > in the introduction to the whitepaper: "With the possibility of > reversal, the need for trust spreads". The problem with that statement is I trust a merchant that I went into a store and made a payment with personally more than I trust the firmware on my hard drive [1]. The attack surface of devices in your computer is huge. A motivated attacker just needs to get an intern into a company that makes some kind of component or system that's in your computer, cloud server, hardware wallet, or what have you that has firmware capable of reading your private keys. With the possibility of mass trojaned hardware, if we are going to trust the system, it must somehow allow reversal through a human-in-the-loop. > There is nothing wrong with having reversible mechanisms built on top > of Bitcoin, and indeed it makes sense for most activity to happen at > those higher layers. It's easy to build things that way, but > impossible to build them the other way: you can't build a > non-reversible layer on top of a reversible layer. We built 'reliable' TCP on top of unreliable ethernet networks. My experience with networking was if you tried to guarantee message delivery at the lowest level, the system got exceedingly complicated, expensive, and brittle. Most applications, in particular paying someone you already trust, are quite happy running on reversible systems, and in some cases more reliable and lower risk. (carrying non-reversible cash is generally considered risky) The problem is that if the base currency is assumed to be non-reversible, then it's brittle and becomes 'too big to fail'. Where the blockchain improves on everything else is in transparency. If you reverse transactions a lot, it will be obvious from an analysis. I would much rather deal with a known, predictable, and relatively continous transaction reversal rate (percentage) than have to deal with sudden failures where some anonymous bad actor makes off with a fortune. We already have zero-conf double-spend transaction reversal, why not explicitly extend that a little in a way that senders and receivers have a choice to use it, or not? [1] http://www.reuters.com/article/2015/02/16/us-usa-cyberspying-idUSKBN0LK1QV20150216 -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
