Re: [Bitcoin-development] Scalability issues
Hi Steve, I see dramatic differences in performance on virtual machines vs running directly on the iron. I am not an expert in virtual machines, but it seems to me that they are weak when it comes to disk i/o. And berkeley DB, as used by bitcoin is a sucker for disk i/o. In top I easily hit >1/#processors in top wa, meaning that the cpu doing the blockchain download is just waiting for the disk all the time. I would like to do a test keeping database log files in memory. It should not matter for durability of the wallet, as it flushes at each write anyway. As for the blockindex, it will remain consistent, but might be lagging some blocks behind at startup, which shouldn't really matter (except that the same block could end up appearing twice in the block00X files, inelegant, but not really a problem). Otherwise the system you describe (raid0 over 6 disks) should perform like crazy wrt disk i/o, at least on par with SSD. It is your virtualization I am worried about. Have a safe trip to down under! /M On 24/07/2012, at 21:56, steve wrote: > Hi Michael, > > from what I have noticed, bitcoin blockchain download/verfication all > happens in 1 thread. (so multicores doesnt really help) > > That said, I have never tried on an ssd. > > What I do have is 6 SATA 6gbs configed as RAID0 Drives. > 32gb of ram. ubuntu 64 (yeah I know), this runs upto 16 VM's > (I have 4 of these) > > However I have not tried to download the blockchain on the master os, > just in virtulisation. However, the dedicated machines that I have been > using for benchmarking the VM's against is a q6600 8gb ram sata2 hdd - > Win 7 (seems faster than slackware...) to me it has always felt like > network bandwidth was the issue. I might instrument the bitcoin-qt exe > to only pick low ping nodes (has someone already done this?) > > I guess it is time to start some benchmarking (like the gpu comparison page) > > hte verification for the 5 past 5 days was negliglable. I am off on a > flight to australia tomorrrow, so I will set some breakpoints and do > some timings in a debugger. > > This will all happen on an e-450 (wonderful machine!) > > Thanks very much for your response. it would seem that I am 'doing it > wrong' :/ > > cheers mate, > > steve > > (this message isnt signed because I have forgotten my password.) > > On 24/07/2012 09:25, Michael Grønager wrote: >> Hi Steve, >> >> 45-90 minutes - note that its numbers from March/April, so a bit >> longer today, but far, far away from the 12 hours. >> >> I am using libcoin and the bitcoind build based on this. Libcoin is >> based on the Satoshi client, but refactured to use an async >> concurrency model. I also did a minor tweeks to the db parameters. It >> has earlier been tested up against Satoshi bitcoin where on some >> OS'es it performs similarly (at least on some linuxes) and on some >> faster (e.g. mac). >> >> What is your CPU load during a block download ? (both initially/up to >> the point where verification sets in and after). The initial download >> is typically disk I/O bound, the verification stage CPU bound, though >> I lean to believe that even there it is disk I/O bound (at least on >> my system ~50% CPU load). What should be better in libcoin is the >> concurrency model. The Satoshi client uses a pure reentrant mutexes >> model, that is not generally believed to motivate the best coding >> practice nor performance, you might end up without the concurrency >> you initially strived for *). As mentioned earlier libcoin uses a >> pure async concurrency model (and so does libbitcoin btw). >> >> I would like to stress again that these numbers will depend largely >> on the system running the test - I would call my laptop a bit over >> the average today (MB Pro, 2.66Ghz i7 dual core, 8GBRAM, 512GB SSD). >> But again 12 hours - I only reach such numbers on some of my VPS'es >> (linode 1024) that are known for notoriously slow disk I/O. (here I >> have a few % CPU load during the verification indicating indeed that >> the disk i/o is the culprit). >> >> Cheers, >> >> Michael >> >> >> *) I like this Dave Butenhof quote: "The biggest of all the big >> problems with recursive mutexes is that they encourage you to >> completely lose track of your locking scheme and scope. This is >> deadly. Evil. It's the "thread eater". You hold locks for the >> absolutely shortest possible time. Period. Always. If you're calling >> something with a lock held simply because you don't know it's held, >> or because you don't know whe
Re: [Bitcoin-development] Scalability issues
Hi Steve, 45-90 minutes - note that its numbers from March/April, so a bit longer today, but far, far away from the 12 hours. I am using libcoin and the bitcoind build based on this. Libcoin is based on the Satoshi client, but refactured to use an async concurrency model. I also did a minor tweeks to the db parameters. It has earlier been tested up against Satoshi bitcoin where on some OS'es it performs similarly (at least on some linuxes) and on some faster (e.g. mac). What is your CPU load during a block download ? (both initially/up to the point where verification sets in and after). The initial download is typically disk I/O bound, the verification stage CPU bound, though I lean to believe that even there it is disk I/O bound (at least on my system ~50% CPU load). What should be better in libcoin is the concurrency model. The Satoshi client uses a pure reentrant mutexes model, that is not generally believed to motivate the best coding practice nor performance, you might end up without the concurrency you initially strived for *). As mentioned earlier libcoin uses a pure async concurrency model (and so does libbitcoin btw). I would like to stress again that these numbers will depend largely on the system running the test - I would call my laptop a bit over the average today (MB Pro, 2.66Ghz i7 dual core, 8GBRAM, 512GB SSD). But again 12 hours - I only reach such numbers on some of my VPS'es (linode 1024) that are known for notoriously slow disk I/O. (here I have a few % CPU load during the verification indicating indeed that the disk i/o is the culprit). Cheers, Michael *) I like this Dave Butenhof quote: "The biggest of all the big problems with recursive mutexes is that they encourage you to completely lose track of your locking scheme and scope. This is deadly. Evil. It's the "thread eater". You hold locks for the absolutely shortest possible time. Period. Always. If you're calling something with a lock held simply because you don't know it's held, or because you don't know whether the callee needs the mutex, then you're holding it too long. You're aiming a shotgun at your application and pulling the trigger. You presumably started using threads to get concurrency; but you've just PREVENTED concurrency." On 23/07/2012, at 17:54, steve wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi Michael, > > On 23/07/2012 10:00, Michael Grønager wrote: >> I get a full blockchain from scratch in 45 minutes on my laptop, >> /M >> > Hang on a sec, in 45 minutes you can download the entire chain from > the genesis block? > > I have been doing extensive testing in this area and would love to > know what is special about your setup (I have never had the entire > chain in under 12 hours, infact it is normally closerto 24.) I have an > extensive setup of test machines, everything from e4300 to phenom2x6 > to i5's. > > as an example on an amd e-450 with 4gb ram, and approx 3gb/s internet > connection it took 2 hours to sync the last 5 days. > > Maybe i am missing something important... > > Any additional information that you could provide to help me with > testing would be really appreciated. > > cheers, > > steve > > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.17 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJQDXO4AAoJEFvEB9dQFvtQxdcH/ieqQkyDCg8mKeOa6CqsWaS6 > fhoeny3Ke2b/CsvhYmsThCvntN9volIqR2CTn5tkHiVwG9OmlxyHZcNpN0ZTHhK5 > lsfLap/Y0QpiysXpV4Bu7Z4Hwp9jnhOP74TshT305r2pX6EGXPQ0CrlHqlIry/X/ > vNcunUclliou+KjL7EHcY50GH5wDpqJAjlNyF97Lj9YiPrAC9vahGwWdxkbCYtG+ > KUuWGBKMMdHuMAgcQh7nI9q0WT3k/gzRQtuC2kf+v0wvQhaGlTVkku4uanhpuw4p > 99blRF3/SfWimGuQgsm6wT3Y7dk+z8MFHLb6XGPxmgV9+gF+TWNczfU3GRzfcXw= > =CQkI > -END PGP SIGNATURE- > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Scalability issues
I would guess that you are running the blockchain download through the tor-proxy - that would give you the times you mention. Further, encrypting your disk (aes stuff) will not help you much either, and encrypting a the storage of a public blockchain seems to me a bit odd ? I get a full blockchain from scratch in 45 minutes on my laptop, but, I still agree with Gregory that scalability improvements are needed, but the problem is far from critical in the sense outlined here. /M On 23/07/2012, at 09:35, Gregory Maxwell wrote: > On Sun, Jul 22, 2012 at 6:37 PM, grarpamp wrote: >> It already takes a month to build a new blockchain, let alone keep up >> with new incoming blocks. > > Please fix your software stack. Something is wrong with your system > and I doubt it has much to do with bitcoin. A full sync here takes > something like an hour. > > There are certainly lots of scalability things going on, but there is > no cause for concern for regular hardware being unable to _keep up_ > without a hardforking change to the protocol first. > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Punishing empty blocks?
Peter, I like the idea of being able to know what fees to expect from different
miners (it is like a service description / SLA for their service), but I would
prefer a more distributed discovery mechanism for the information on the fees
(Spent 10 years on Grid Computing...).
Miners could e.g. include a pointer to a webpage (or even their min fee) in the
coinbase (encoded properly, like the "/P2SH/" string for BIP0016). That way
clients could look it up them selves or you could create sites accumulating
this information from the chain it self.
So something like :
const char* service_sla =
"|https://my_ubercool_asic_mining_pool/sla.php|";
COINBASE_FLAGS << std::vector(service_sla,
service_sla+strlen(service_sla));
The format of the sla.php page should then be specified too - but it could be a
json-rpc call returning a json object like (as result):
{
sla_version: "0.1",
accept_no_fee_tx: false,
min_fee: 5,
big_tx_fee: 1, // extra fee pr kb
}
I guess miners could work out a more suitable set of fees...
Seems like this calls for a BIP ?
/M
On 28/05/2012, at 16:54, Peter Vessenes wrote:
> One of the issues here though is that it would be nice if miners published
> their own tx rules -- it might be hard to impute them from data.
>
> I had started a thread about this on bitcoin.org some time ago, and I don't
> recall what the general outcome was.
>
> I had imagined an open service whereby a miner could publish a short string
> in their conbase tying to the service and the service would have different
> metadata, including the miner's transaction guarantees.
>
> We offered to host this before, and would still be willing to host such a
> service.
>
> Peter
>
> On Sat, May 26, 2012 at 7:52 AM, Stefan Thomas wrote:
> Zooko is spot on - slower confirmations will give people a reason to set
> higher fees. As soon as fees reach a level where they matter, even
> botnet operators will be looking into ways of including transactions for
> some extra profit.
>
> In the meantime slightly slower confirmations aren't a problem. Consider
> that even if it takes four blocks to get your transaction included
> instead of one, once it is included, you still benefit from every new
> block in terms of security. So if you're looking for six confirmations
> for example, even a three block delay will only be a 50% delay for you.
> And of course there are techniques for instant transactions which
> continue to be refined and improved.
>
> As for the proposed solutions: Punishing 1-tx blocks is complete and
> utter nonsense. It's trivial to include a bogus second transaction.
>
> Any additional challenges towards miners like hashes of the previous
> block are at best useless. If I was running a botnet, I'd just grab that
> hash from a website (pretty good chance Blockchain.info will have it :P)
> or mining pool or wherever and keep going undeterred. At worst they may
> affect scalability one day. You might imagine a peer-to-peer network of
> miners who for cost reasons don't download all blocks anymore, but
> verify only a percentage of them at random. They might then exchange
> messages about invalid blocks including a proof (invalid tx, merkle
> branch) why the block is invalid. This is just one idea, the point is
> that assumptions about what a legitimate miner looks like may not always
> hold in the future.
>
> Finally, there is an ethical aspect as well. If a miner wishes not to
> include my transaction that is his choice. He has no more an obligation
> to sell his service to me than I have to buy it from him. If I really,
> really want him to include my transaction I will have to offer to pay more.
>
> If we as developers think that confirmations are too slow or that more
> blocks should include transactions, then the right measures would be:
>
> - Educating users about the relationship between confirmation speed and fees
> - Raising the default transaction fee
>
> Every market has a supply curve, so it is economically to be expected
> that there will be some miners who don't include transactions, simply
> because they are at that end of the supply curve where it is not worth
> it for them to sell their service. All markets must have a certain
> tension - there must be miners who don't include transactions for there
> to be users who want their transactions included more quickly. In other
> words there must be somebody not confirming if confirmations are to have
> value. If you interfere with that all you'll accomplish is keep
> transaction fees below market level, which will make the transition from
> inflation-financed hashing to transaction-financed hashing more painful
> and disruptive.
>
> Cheers,
>
> Stefan
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respo
Re: [Bitcoin-development] Signature Blocks and URI Sign Requests
Hi Alan, I am using an approach similar to your proposal in a service I am developing. I have, however, chosen to sign using the following scheme: 1. take sha512 of document (=hash512) 2. take ripemd160 of hash512 3. create 512 bit data structure, where the first 352bits are '0', and the rest is the ripemd160 of our hash512 4. sign it with the key This procedure prevents an evil site from fooling you to sign a transaction spending your own coins. So bottom like never sign a full sha512 with a key for any other purpose than a transaction. (The above could easily well have been implemented as just truncating the hash512 to 256 bits, feel free to propose the optimal scheme). /M On 04/04/2012, at 08:23, Wladimir wrote: > Alan, > > On Wed, Apr 4, 2012 at 2:01 AM, Alan Reiner wrote: > There is all this fanfare around P2SH and how multi-sig is the solution to > all these security problems, but how the hell do you use it? I believe that > BIP 10 (or successor) is critical to the success of multi-sig, because the > greatest barrier to using multi-sig will be the ability to actually execute > them in less than 14 steps. And if every client implements it differently, > there's even less chance it will be used (assuming the userbase reaches any > level of client diversity). > > That is a laudable goal. > > So your proposal is about signing "Preformatted messages from sites" to make > financial transactions more secure, not arbitrary user-to-user messages such > as email. That really restricts the scope, which is good. > > In this case there is no use for S/MIME, which deals with encoding/signing > multipart mail messages. And no need to deal with MIME headers, html, or > embedded images, and such. And we can simply require one character encoding, > no need to support hundreds. > > The "request signing" bitcoin URL makes sense in my eyes. Less copy/pasting > is good. Do mind that there is usually a URL size limit (depending on the > browser) so this cannot be used for long messages/contracts. A possible > solution would be to make an option to pass the address where the message can > be retrieved (and maybe also where the signature must be sent, to save a > copy-paste back?). > > Looking at existing solutions, the only other "sign request" that I know of > is the CSR (https://en.wikipedia.org/wiki/Certificate_signing_request) but > the functionality and goal is very different. > > It'd be useful (and IMO most important) to write down some use-cases in which > this makes P2SH easier and less involved. How many steps can be eliminated of > the 14? > > Wladimir > BTW: we also still need a BIP to define URL signing / authentication itself. > > -- > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.7 merge recommendations/status
If you are interested, I could push libcoin to bitcoin (e.g. bitcoin/libcoin) and then you could build bitcoind bitcoin-qt on libcoin. libcoin solved most of the problems you list below. And if you worry about the copyright/license I am also willing to change that to make it fit. libcoin have no global thread mutexes and and there is no blocking of the main thread due to rpc methods (except for a sendto), further, e.g. a reorganize only locks the main thread for a split second while the final commit is done. The libcoin rpc supports keep_alive and pipelining, runs in its own thread (but can also run in the same thread as the node) and uses async operation. Ipv6 is easy to implement in libcoin as the CAddress/Endpoint class is implemented as a subclass of boost::endpoint, only thing holding back is deciding on an ipv6 format on IRC, and, I then I would really like to reverse the order of the last 12 bytes in the address db (they are opposite to boost). Cheers, Michael On 31/03/2012, at 12:54, Pieter Wuille wrote: > On Sat, Mar 31, 2012 at 12:03:17AM -0400, Luke-Jr wrote: >> NOTE: I've been piecing this together for about a week now, and intended to >> update it when 0.6.0 final was released, but with the timing of it, I just >> won't get the time to update for a while, so here is my last draft... > > Nice summary, thanks. > >> It seems to me, there is potentially enough ready to merge into 0.7 to start >> the RC process right away if someone wants to... except that the first merge >> will probably require rebasing everything else ;) > > I think that's right - for several reasons, the time between 0.5 and 0.6 was > over 4 months. I prefer more frequent releases, as it slows down development > this way. > >> For similar reasons as CBlockStore, I feel multithreaded JSON-RPC with keep- >> alive support (#568) should be merged sooner rather than later. It's long >> overdue for bitcoind having had a lot of testing, and pretty much required >> for >> any sort of high-volume bitcoind usage (such as solo mining). Some other >> optimizations by Joel such as the optimized ToHex function (#562) and >> FastGetWork (#565) have also had plenty of testing; all combined, these >> optimizations more than double the performance of JSON-RPC. >> Details: https://github.com/bitcoin/bitcoin/pull/565#issuecomment-3269334 > > I'd rather see a decent encapsulation of wallet and blockchain data structures > that allow us to make their mutexes private, and let only the code from the > respective mutex take locks in it when necessary. That will automatically > lead to multithreaded RPC, but in a safe way, without needing guesswork about > which two calls may or may not be called simultaneously. > > Of course, that requires a lot more work, but at some point that will be > needed > anyway, imho. > >> Pieter's getalltransactions (#841) and my getblock_full (#886) provide what >> is >> needed to completely replace Jeff's old dumpblock call with bitcoind's new >> getblock. He also put together a -loadblock option (#883) which has proven >> quite handy for development, and -walletupgrade (#974) seems like a good >> idea. > > I've used loadblocks often in my personal branches. At least on Linux it seems > to work fine. The data scanning code is mostly Cish though, and there may be > more preferrable to use boost or generic C++ solutions. > >> Finally, I don't know the status of Pieter's IPv6 support, but I hope it >> will >> be ready for 0.7. Right now all I see submitted for this is support for >> multiple local IPs (#829) though. > > I've already had a fully functional IPv6 node based on 0.3.24. Most of the > changes > there have since been incorported in netbase (#735), and because of a risk > for DoS'es > based on the much larger number of addresses an attacker could have under his > control, > addrman (#787) was necessary before IPv6 could be fully implemented. So, the > technical > part of supporting IPv6 seems mostly finished - right now, it's mostly just > removing > some (!IsIPv4()) checks and adding listen/connect code that is > IPv6-compatible. > I'll do a pullreq for that soon. > > There are a few other issues, though. For example: how will relaying work: > will IPv4 > nodes relay IPv6 addresses? If not, the IPv6 bitcoin network will be > completely > separate from the IPv4 one, though both may overlap in some points. The > opposite is > also possible: allowing all nodes to relay IPv6 addresses, but only use them > in case > an IPv6-compatible interface is detected. Any opinions about this? > > Something else was suggested by Jeff: what if a node accidentally connects to > itself? > As we're moving towards multiple local addresses with IPv6, the chances for > this > become larger. Finally, there are always extra risks involved, as we could > unknowingly > be opening DoS or others vulnerabilities. > > Finally, supporting IPv6 in a somewhat general way would pave the wa
Re: [Bitcoin-development] Announcement: libcoin
What you list below was actually the plan - just havn't gotten there yet, but
it will be dead easy.
/M
On 22/03/2012, at 11:50, Martinx - ジェームズ wrote:
> Michael,
>
> Since libcoin is "chain agnostic", I was wondering if the project can be
> used like this:
>
> When I install it with "make install", I would like to have something like
> this:
>
> Regular file: /usr/local/bin/libcoincore # or whatever you like
>
> Symlink -> Regular file
>
> /usr/local/bit/bitcoind -> /usr/local/bin/libcoincore # bitcoind is a
> symlink to libcoincore
>
> /usr/local/bit/litecoind -> /usr/local/bin/libcoincore # litecoind is a
> symlink to libcoincore
>
> /usr/local/bit/devcoind -> /usr/local/bin/libcoincore # devcoind is a
> symlink to libcoincore
>
> /usr/local/bit/namecoind -> /usr/local/bin/libcoincore # devcoind is a
> symlink to libcoincore
>
> ...and so on...
>
> So, libcoincore will interpret the ARGV[0] and, for each string, it will
> initiate the appropriate internal functions...
>
> I don't know if Libcoin already does something like that... I'm not a
> developer/code reader... Just a small nerd with big ideas... ^_^
>
> Thanks!
> Thiago
>
> 2012/2/28 Michael Grønager
> Hi again - and thanks for testing and finding this!
>
> I have fixed the bug you reported:
>
> The culprit was an implicit string constructor for the ChainAddress that
> caused creation of a not fully initialized ChainAddress. The right way to do
> it is using chain::getAddress(string) as the ChainAddress is chain specific.
>
> A git pull will fix it ;)
>
> Cheers,
>
> Michael
>
>
> On 27/02/2012, at 20:03, Martinx - ジェームズ wrote:
>
> > AWESOME!! Thank you!!
> >
> > Anyway, I found a new problem... lol
> >
> > /usr/local/bin/bitcoind getinfo #okay
> > {
> >"version" : 40001,
> >"blocks" : 168753,
> >"connections" : 8,
> >"difficulty" : 1376302.26788638,
> >"testnet" : false
> > }
> >
> > /usr/local/bin/bitcoind getaccountaddress "" # okay...
> > 1J4vNcvEdeCuLH4yvyoC2gxFEF4zquoJ87
> >
> > /usr/local/bin/bitcoind listaccounts # NOT okay...
> > {
> > }
> >
> > /usr/local/bin/bitcoind getaccountaddress "teste" # okay
> > 1E6pGh6AAtuJdFXheZMp1zdYmvdqAQn9QT
> >
> > /usr/local/bin/bitcoind listaccounts # NOT okay...
> > {
> >"teste" : 0.
> > }
> >
> > Where is my default account listed at "listaccounts" output?!
> >
> > Best,
> > Thiago
> >
> > 2012/2/26 Michael Grønager
> > And if you do an update now "help" is there too ;)
> >
> > /M
> >
> > On 25/02/2012, at 03:11, Martinx - ジェームズ wrote:
> >
> >> Thank you!!!
> >>
> >> It is all working now! Except "help"...
> >>
> >> Nice work Michael!!
> >>
> >> Best,
> >> Thiago
> >>
> >> 2012/2/24 Michael Grønager
> >> OK - didn't took the weekend:
> >>
> >> support for "port" is on github now :)
> >>
> >> Only took two lines:
> >>
> >> ("port", value(&port)->default_value(8333),
> >> "Listen on specified port for the p2p protocol")
> >>
> >> and using the port option in the Node constructor (was there already):
> >>
> >> Node node(chain, data_dir, args.count("nolisten") ? "" : "0.0.0.0",
> >> lexical_cast(port)); // it is also here we specify the use of a
> >> proxy!
> >>
> >> /M
> >>
> >>
> >>
> >> On 24/02/2012, at 19:49, Martinx - ジェームズ wrote:
> >>
> >>> Hi Michael,
> >>>
> >>> Thank you for your attention!
> >>>
> >>> Now, I'm trying to start libcoin's bitcoind using high ports but, it
> >>> always try to listen at 8332, no matter what I "say"...
> >>>
> >>> Look:
> >>>
> >>> $ cat .bitcoin/bitcoin.conf
> >>> server=1
> >>> daemon=1
> >>> rpcuser=libcoin
> >>> rpcpassword=LibCoin13
> >>> rpcport=10332
> >>> port=10333
> >>>
> >>> But:
> >>>
> >>> /usr/local/bin/bitcoind
> >>> Error: Address already in use
> >>>
> >>&g
Re: [Bitcoin-development] Announcement: libcoin
>
> 1- How close is Libcoin with original Bitcoin? I mean, the output is a
> little different, the bitcoind help output was disabled and, I'm afraid that
> Libcoin can possibly being distant from Bitcoin in the future... That can
> happen?!
Well, I hope at some point to push libcoin to bitcoin, but that is not for me
to decide ;)
Anyway, I will strive at keeping the two synced - currently, they are almost in
sync - even bip 16 is part of libcoin, but I have postponed generation of P2SH
till after we were certain of 16 vs 17. So that is high on the list.
I did a presentation of libcoin at BitCon12 in San Antonio - I will trow the
slides at the web-side asap.
>
> 2- Do you have plans to update Libcoin on every new upstream Bitcoin
> release? How fast will be this updates? Do you need more resources/people
> working on it?
More people is always nice! I am using libcoin for my own bitcoin project, so
that should guarantee that it will be kept up to date.
> Another questions not involved directly with Libcoin/Bitcoin but, I'll need
> it for my future Bitcoin projects, and Libcoin is on my radar:
>
> 1- Do you know about Diaspora* Project?
Yes, I even have an account :)
> 2- Do you have skills in Ruby on Rails development?
Nope...
/M
>
>
> Thank you!
> Thiago
>
> 2012/3/3 Michael Grønager
> Hi Martin,
>
> There are a couple of options of doing similarly...
>
> In the libcoin repository you will find some code for btc and btcd, it is
> some code I wrote a while ago and it needs to be updated. It functions as a
> bitcoind master and slave. The btcd keeps the blockchain, but no wallet. btc
> keeps the wallet and contact the btcd to get transaction info (like send an
> address and get its transactions or send a transaction id and get its
> details). It works (or worked when I wrote them) with the wallet.dat, but
> needs a little update.
>
> You could e.g. run one btcd on the machine and several btc instances to get
> the functionality you asked for.
>
> Further, btcd also enables a web wallet, where the private keys are stored in
> your browsers local-store.
>
> I will get the application updated, but most likely in a bit other setup as
> it is something I intend to marketize in the near future.
>
> Hope this answers your question.
>
> Cheers,
>
> Michael
>
> On 03/03/2012, at 02:04, Martinx - ジェームズ wrote:
>
> > Michael,
> >
> > libcoin is AWESOME! Thanks!!!
> >
> > Can I do the following scenario with libcoin ? :
> >
> > 1- Create a regular Linux user called "blockchain", with home dir pointed
> > to /var/lib/libcoin/ (more or like Ubuntu/Debian mysql does);
> >
> > 2- Start "bitcoind" under user "blockchain" (the Bitcoin blockchain) will
> > be downloaded to /var/lib/libcoin/bitcoin/ directory);
> >
> > 3- As another regular user, called "michael", I would like to run
> > "bitcoind" too but, I do not want to re-download the blockchain to its own
> > subdir, I want instead, to consult it (blockchain) through libcoin itself
> > (not by socket of JSON)...
> >
> > So, the /home/michael/.bitcoin/ directory will have only wallet.dat and
> > related files, not the blockchain.
> >
> > This is more or less what we can do with Bitcoin Electrum alternate client
> > but, with Electrum, it copy the whole blockchain to mysql... This is
> > terrible from my point of view, I think that there is no need to duplicate
> > the blockchain within MySQL in anyway.
> >
> > I just imagine a bitcoin splited in two, blockchain in one side and wallet
> > in the other side.
> >
> > This is possible with libcoin?!
> >
> > Thank you again!
> >
> > Best,
> > Thiago
> >
> > 2012/2/28 Michael Grønager
> > Hi again - and thanks for testing and finding this!
> >
> > I have fixed the bug you reported:
> >
> > The culprit was an implicit string constructor for the ChainAddress that
> > caused creation of a not fully initialized ChainAddress. The right way to
> > do it is using chain::getAddress(string) as the ChainAddress is chain
> > specific.
> >
> > A git pull will fix it ;)
> >
> > Cheers,
> >
> > Michael
> >
> >
> > On 27/02/2012, at 20:03, Martinx - ジェームズ wrote:
> >
> >> AWESOME!! Thank you!!
> >>
> >> Anyway, I found a new problem... lol
> >>
> >> /usr/local/bin/bitcoind getinfo #okay
> >> {
> >> "version" : 40001,
> >> "blocks" : 168753,
> >> "
Re: [Bitcoin-development] Adding callback hooks to the satoshi client
Hi Eric, What hooks are you looking for in particular ? libcoin supports registration of listeners for new blocks and new transactions. These are e.g. used for connecting the Wallet to the Node. Cheers, M On 22/03/2012, at 06:39, bitcoin-l...@bluematt.me wrote: > 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 Michael Gronager, PhD Director, Ceptacle Jens Juels Gade 33 2100 Copenhagen E Mobile: +45 31 45 14 01 E-mail: grona...@ceptacle.com Web: http://www.ceptacle.com/ -- 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
Sounds interesting, however, even after a couple of days, I cannot see how you
maintain protection against double spend using OP_CHECKEXPSIG. It is not until
you redeem the OP_CHECKEXPSIG transaction that you reveal which former
transactions that was involved?
I guess I am missing a point here?
/M
On 02/03/2012, at 20:57, 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.
>
> Name: OP_CHECKEXPSIG
> Stack before:
> Stack after: T/F, where is true if sig is a ECDSA signature under pk
> for the hash hash. (Hash is the hash of a message).
> Uses: Preexisting digital cash techniques relied on keeping track of a
> list of turned in notes to forbid double spending. Using
> OP_CHECKEXPSIG we can instead pass the script that gives the nth note
> value proof that the notes {1,...n-1} were turned in and are distinct.
> This enables a coupling of the strong double spend protection of
> Bitcoin with traditional digital cash's strong anonymity.
>
> Sincerely,
> Watson Ladd
>
> --
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Michael Gronager, PhD
Director, Ceptacle
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 45 14 01
E-mail: grona...@ceptacle.com
Web: http://www.ceptacle.com/
--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] getmemorypool BIP process
> > HTTP and JSON-RPC are a client-server model; there is no way for the server > to > make calls to the client. It's not practical to expect clients to run their > own JSON-RPC server - many cannot listen on WAN ports at all. Well, I think what Stefan had in mind was http keep-alive combined with an event system. So similar to the way a web chat application work, just for json-rpc. BitcoinJS already uses this for realtime updating a webwallet. Libcoin is also prepared for this with a quite advanced, non-blocking, http server so I second Stefan that an update function could indeed be of relevance. Btw - question to Stefan as the JavaScript guru - what do you consider the standard/defacto-standard/right/best-practice way of doing S->C json-rpc, what (javascript) library do you use for this? Cheers, Michael > > -- > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Announcement: libcoin
Hi again - and thanks for testing and finding this!
I have fixed the bug you reported:
The culprit was an implicit string constructor for the ChainAddress that caused
creation of a not fully initialized ChainAddress. The right way to do it is
using chain::getAddress(string) as the ChainAddress is chain specific.
A git pull will fix it ;)
Cheers,
Michael
On 27/02/2012, at 20:03, Martinx - ジェームズ wrote:
> AWESOME!! Thank you!!
>
> Anyway, I found a new problem... lol
>
> /usr/local/bin/bitcoind getinfo #okay
> {
>"version" : 40001,
>"blocks" : 168753,
>"connections" : 8,
>"difficulty" : 1376302.26788638,
>"testnet" : false
> }
>
> /usr/local/bin/bitcoind getaccountaddress "" # okay...
> 1J4vNcvEdeCuLH4yvyoC2gxFEF4zquoJ87
>
> /usr/local/bin/bitcoind listaccounts # NOT okay...
> {
> }
>
> /usr/local/bin/bitcoind getaccountaddress "teste" # okay
> 1E6pGh6AAtuJdFXheZMp1zdYmvdqAQn9QT
>
> /usr/local/bin/bitcoind listaccounts # NOT okay...
> {
>"teste" : 0.
> }
>
> Where is my default account listed at "listaccounts" output?!
>
> Best,
> Thiago
>
> 2012/2/26 Michael Grønager
> And if you do an update now "help" is there too ;)
>
> /M
>
> On 25/02/2012, at 03:11, Martinx - ジェームズ wrote:
>
>> Thank you!!!
>>
>> It is all working now! Except "help"...
>>
>> Nice work Michael!!
>>
>> Best,
>> Thiago
>>
>> 2012/2/24 Michael Grønager
>> OK - didn't took the weekend:
>>
>> support for "port" is on github now :)
>>
>> Only took two lines:
>>
>> ("port", value(&port)->default_value(8333), "Listen
>> on specified port for the p2p protocol")
>>
>> and using the port option in the Node constructor (was there already):
>>
>> Node node(chain, data_dir, args.count("nolisten") ? "" : "0.0.0.0",
>> lexical_cast(port)); // it is also here we specify the use of a
>> proxy!
>>
>> /M
>>
>>
>>
>> On 24/02/2012, at 19:49, Martinx - ジェームズ wrote:
>>
>>> Hi Michael,
>>>
>>> Thank you for your attention!
>>>
>>> Now, I'm trying to start libcoin's bitcoind using high ports but, it always
>>> try to listen at 8332, no matter what I "say"...
>>>
>>> Look:
>>>
>>> $ cat .bitcoin/bitcoin.conf
>>> server=1
>>> daemon=1
>>> rpcuser=libcoin
>>> rpcpassword=LibCoin13
>>> rpcport=10332
>>> port=10333
>>>
>>> But:
>>>
>>> /usr/local/bin/bitcoind
>>> Error: Address already in use
>>>
>>> terminate called after throwing an instance of 'DbException'
>>> what(): DbEnv::close: Invalid argument
>>> Aborted
>>>
>>> When I "strace it", I can see:
>>>
>>> ...
>>> bind(12, {sa_family=AF_INET, sin_port=htons(8333),
>>> sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
>>> ...
>>>
>>> I already tried:
>>>
>>> /usr/local/bin/bitcoind --rpcport 10332
>>> /usr/local/bin/bitcoind --rpcport=10332
>>>
>>> Without success...
>>>
>>> Thanks again!
>>> Thiago
>>>
>>> 2012/2/24 Michael Grønager
>>> Hi Thiago,
>>>
>>> Forgot to comment on the two latter:
>>>
>>>> $ bitcoind getaccountaddress ""
>>>> HTTP error code: 401
>>>> Error: couldn't parse reply from server
>>>>
>>>> $ bitcoind listaccounts
>>>> HTTP error code: 401
>>>> Error: couldn't parse reply from server
>>>>
>>>
>>> 401 = permission denied - you need to setup username / password either on
>>> the commandline or in the bicoin.conf file to access those commands...
>>>
>>> See in the bitcoind.cpp file for commands that you can use with and without
>>> auth...
>>>
>>> Those that contains an "auth" requires auth:
>>>
>>> server.registerMethod(method_ptr(new GetBalance(wallet)), auth);
>>>
>>> As opposed to:
>>>
>>> server.registerMethod(method_ptr(new GetInfo(node)));
>>>
>>> auth is defined by:
>>>
>>> Auth auth(rpc_user, rpc
Re: [Bitcoin-development] Announcement: libcoin
I tried this and got:
./bitcoind listaccount:
{
}
bitcoind getnewaddress
1DumTDw6quNqnUegJsXL2AJjDA9fmxRY7o
./bitcoind setaccount 1DumTDw6quNqnUegJsXL2AJjDA9fmxRY7o test
./bitcoind listaccounts{
"" : 0.,
"test" : 0.
}
Seem like the default account ( "" ) need to be initialized ?? Will test the
same with the old client and see if it behaves similarly..
/M
On 27/02/2012, at 20:03, Martinx - ジェームズ wrote:
> AWESOME!! Thank you!!
>
> Anyway, I found a new problem... lol
>
> /usr/local/bin/bitcoind getinfo #okay
> {
>"version" : 40001,
>"blocks" : 168753,
>"connections" : 8,
>"difficulty" : 1376302.26788638,
>"testnet" : false
> }
>
> /usr/local/bin/bitcoind getaccountaddress "" # okay...
> 1J4vNcvEdeCuLH4yvyoC2gxFEF4zquoJ87
>
> /usr/local/bin/bitcoind listaccounts # NOT okay...
> {
> }
>
> /usr/local/bin/bitcoind getaccountaddress "teste" # okay
> 1E6pGh6AAtuJdFXheZMp1zdYmvdqAQn9QT
>
> /usr/local/bin/bitcoind listaccounts # NOT okay...
> {
>"teste" : 0.
> }
>
> Where is my default account listed at "listaccounts" output?!
>
> Best,
> Thiago
>
> 2012/2/26 Michael Grønager
> And if you do an update now "help" is there too ;)
>
> /M
>
> On 25/02/2012, at 03:11, Martinx - ジェームズ wrote:
>
>> Thank you!!!
>>
>> It is all working now! Except "help"...
>>
>> Nice work Michael!!
>>
>> Best,
>> Thiago
>>
>> 2012/2/24 Michael Grønager
>> OK - didn't took the weekend:
>>
>> support for "port" is on github now :)
>>
>> Only took two lines:
>>
>> ("port", value(&port)->default_value(8333), "Listen
>> on specified port for the p2p protocol")
>>
>> and using the port option in the Node constructor (was there already):
>>
>> Node node(chain, data_dir, args.count("nolisten") ? "" : "0.0.0.0",
>> lexical_cast(port)); // it is also here we specify the use of a
>> proxy!
>>
>> /M
>>
>>
>>
>> On 24/02/2012, at 19:49, Martinx - ジェームズ wrote:
>>
>>> Hi Michael,
>>>
>>> Thank you for your attention!
>>>
>>> Now, I'm trying to start libcoin's bitcoind using high ports but, it always
>>> try to listen at 8332, no matter what I "say"...
>>>
>>> Look:
>>>
>>> $ cat .bitcoin/bitcoin.conf
>>> server=1
>>> daemon=1
>>> rpcuser=libcoin
>>> rpcpassword=LibCoin13
>>> rpcport=10332
>>> port=10333
>>>
>>> But:
>>>
>>> /usr/local/bin/bitcoind
>>> Error: Address already in use
>>>
>>> terminate called after throwing an instance of 'DbException'
>>> what(): DbEnv::close: Invalid argument
>>> Aborted
>>>
>>> When I "strace it", I can see:
>>>
>>> ...
>>> bind(12, {sa_family=AF_INET, sin_port=htons(8333),
>>> sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
>>> ...
>>>
>>> I already tried:
>>>
>>> /usr/local/bin/bitcoind --rpcport 10332
>>> /usr/local/bin/bitcoind --rpcport=10332
>>>
>>> Without success...
>>>
>>> Thanks again!
>>> Thiago
>>>
>>> 2012/2/24 Michael Grønager
>>> Hi Thiago,
>>>
>>> Forgot to comment on the two latter:
>>>
>>>> $ bitcoind getaccountaddress ""
>>>> HTTP error code: 401
>>>> Error: couldn't parse reply from server
>>>>
>>>> $ bitcoind listaccounts
>>>> HTTP error code: 401
>>>> Error: couldn't parse reply from server
>>>>
>>>
>>> 401 = permission denied - you need to setup username / password either on
>>> the commandline or in the bicoin.conf file to access those commands...
>>>
>>> See in the bitcoind.cpp file for commands that you can use with and without
>>> auth...
>>>
>>> Those that contains an "auth" requires auth:
>>>
>>> server.registerMethod(method_ptr(new GetBalance(wallet)), auth);
>>>
>>> As opposed to:
>>>
>>> server.registerMethod(method_ptr(new GetInfo(node)));
>>>
>>> auth is de
Re: [Bitcoin-development] Announcement: libcoin
And if you do an update now "help" is there too ;)
/M
On 25/02/2012, at 03:11, Martinx - ジェームズ wrote:
> Thank you!!!
>
> It is all working now! Except "help"...
>
> Nice work Michael!!
>
> Best,
> Thiago
>
> 2012/2/24 Michael Grønager
> OK - didn't took the weekend:
>
> support for "port" is on github now :)
>
> Only took two lines:
>
> ("port", value(&port)->default_value(8333), "Listen
> on specified port for the p2p protocol")
>
> and using the port option in the Node constructor (was there already):
>
> Node node(chain, data_dir, args.count("nolisten") ? "" : "0.0.0.0",
> lexical_cast(port)); // it is also here we specify the use of a proxy!
>
> /M
>
>
>
> On 24/02/2012, at 19:49, Martinx - ジェームズ wrote:
>
>> Hi Michael,
>>
>> Thank you for your attention!
>>
>> Now, I'm trying to start libcoin's bitcoind using high ports but, it always
>> try to listen at 8332, no matter what I "say"...
>>
>> Look:
>>
>> $ cat .bitcoin/bitcoin.conf
>> server=1
>> daemon=1
>> rpcuser=libcoin
>> rpcpassword=LibCoin13
>> rpcport=10332
>> port=10333
>>
>> But:
>>
>> /usr/local/bin/bitcoind
>> Error: Address already in use
>>
>> terminate called after throwing an instance of 'DbException'
>> what(): DbEnv::close: Invalid argument
>> Aborted
>>
>> When I "strace it", I can see:
>>
>> ...
>> bind(12, {sa_family=AF_INET, sin_port=htons(8333),
>> sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
>> ...
>>
>> I already tried:
>>
>> /usr/local/bin/bitcoind --rpcport 10332
>> /usr/local/bin/bitcoind --rpcport=10332
>>
>> Without success...
>>
>> Thanks again!
>> Thiago
>>
>> 2012/2/24 Michael Grønager
>> Hi Thiago,
>>
>> Forgot to comment on the two latter:
>>
>>> $ bitcoind getaccountaddress ""
>>> HTTP error code: 401
>>> Error: couldn't parse reply from server
>>>
>>> $ bitcoind listaccounts
>>> HTTP error code: 401
>>> Error: couldn't parse reply from server
>>>
>>
>> 401 = permission denied - you need to setup username / password either on
>> the commandline or in the bicoin.conf file to access those commands...
>>
>> See in the bitcoind.cpp file for commands that you can use with and without
>> auth...
>>
>> Those that contains an "auth" requires auth:
>>
>> server.registerMethod(method_ptr(new GetBalance(wallet)), auth);
>>
>> As opposed to:
>>
>> server.registerMethod(method_ptr(new GetInfo(node)));
>>
>> auth is defined by:
>>
>> Auth auth(rpc_user, rpc_pass); // if rpc_user and rpc_pass are not set,
>> all authenticated methods becomes disallowed.
>>
>> so you just experience the case explained in the comment ;) I admit that the
>> output could be more readable, though!
>>
>> /M
>>
>>
>>>
>>> Any tips?! lol
>>>
>>> Thanks!
>>> Thiago
>>>
>>> 2012/2/23 Martinx - ジェームズ
>>> AWESOME!!!
>>>
>>> I can compile libcoin at my Ubuntu 11.10... I just need to install:
>>>
>>> sudo aptitude install libboost1.46-all-dev
>>>
>>> ...alongside with another already installed dependencies, and now it works!!
>>>
>>> Thank you!
>>> Thiago
>>>
>>> 2012/2/23 Michael Grønager
>>> Hi Martinx,
>>>
>>> Another note:
>>>
>>> boost 1.42 and openssl 1.0 has a conflict (you will see it when you try to
>>> compile coinHTTP with that specific combination: sslv2 has been removed
>>> from openssl, but boost still references it.)
>>>
>>> You should do a :
>>>
>>> sudo apt-get upgrade libboost-dev-all
>>>
>>> to get the 1.46.1 library
>>>
>>> /M
>>>
>>>
>>> On 23/02/2012, at 18:31, Martinx - ジェームズ wrote:
>>>
>>>> Hi Michael!
>>>>
>>>> Thank you for libcoin! It is a awesome evolution for Bitcoin and for the
>>>> CryptoCurrencies as a hole... Thanks!!!
>>>>
>>>> Anyway, I am unable to compile libcoin under my Ubuntu 11.04. At this
>>>> m
Re: [Bitcoin-development] Announcement: libcoin
OK - didn't took the weekend:
support for "port" is on github now :)
Only took two lines:
("port", value(&port)->default_value(8333), "Listen
on specified port for the p2p protocol")
and using the port option in the Node constructor (was there already):
Node node(chain, data_dir, args.count("nolisten") ? "" : "0.0.0.0",
lexical_cast(port)); // it is also here we specify the use of a proxy!
/M
On 24/02/2012, at 19:49, Martinx - ジェームズ wrote:
> Hi Michael,
>
> Thank you for your attention!
>
> Now, I'm trying to start libcoin's bitcoind using high ports but, it always
> try to listen at 8332, no matter what I "say"...
>
> Look:
>
> $ cat .bitcoin/bitcoin.conf
> server=1
> daemon=1
> rpcuser=libcoin
> rpcpassword=LibCoin13
> rpcport=10332
> port=10333
>
> But:
>
> /usr/local/bin/bitcoind
> Error: Address already in use
>
> terminate called after throwing an instance of 'DbException'
> what(): DbEnv::close: Invalid argument
> Aborted
>
> When I "strace it", I can see:
>
> ...
> bind(12, {sa_family=AF_INET, sin_port=htons(8333),
> sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
> ...
>
> I already tried:
>
> /usr/local/bin/bitcoind --rpcport 10332
> /usr/local/bin/bitcoind --rpcport=10332
>
> Without success...
>
> Thanks again!
> Thiago
>
> 2012/2/24 Michael Grønager
> Hi Thiago,
>
> Forgot to comment on the two latter:
>
> > $ bitcoind getaccountaddress ""
> > HTTP error code: 401
> > Error: couldn't parse reply from server
> >
> > $ bitcoind listaccounts
> > HTTP error code: 401
> > Error: couldn't parse reply from server
> >
>
> 401 = permission denied - you need to setup username / password either on the
> commandline or in the bicoin.conf file to access those commands...
>
> See in the bitcoind.cpp file for commands that you can use with and without
> auth...
>
> Those that contains an "auth" requires auth:
>
> server.registerMethod(method_ptr(new GetBalance(wallet)), auth);
>
> As opposed to:
>
> server.registerMethod(method_ptr(new GetInfo(node)));
>
> auth is defined by:
>
> Auth auth(rpc_user, rpc_pass); // if rpc_user and rpc_pass are not set,
> all authenticated methods becomes disallowed.
>
> so you just experience the case explained in the comment ;) I admit that the
> output could be more readable, though!
>
> /M
>
>
> >
> > Any tips?! lol
> >
> > Thanks!
> > Thiago
> >
> > 2012/2/23 Martinx - ジェームズ
> > AWESOME!!!
> >
> > I can compile libcoin at my Ubuntu 11.10... I just need to install:
> >
> > sudo aptitude install libboost1.46-all-dev
> >
> > ...alongside with another already installed dependencies, and now it works!!
> >
> > Thank you!
> > Thiago
> >
> > 2012/2/23 Michael Grønager
> > Hi Martinx,
> >
> > Another note:
> >
> > boost 1.42 and openssl 1.0 has a conflict (you will see it when you try to
> > compile coinHTTP with that specific combination: sslv2 has been removed
> > from openssl, but boost still references it.)
> >
> > You should do a :
> >
> > sudo apt-get upgrade libboost-dev-all
> >
> > to get the 1.46.1 library
> >
> > /M
> >
> >
> > On 23/02/2012, at 18:31, Martinx - ジェームズ wrote:
> >
> >> Hi Michael!
> >>
> >> Thank you for libcoin! It is a awesome evolution for Bitcoin and for the
> >> CryptoCurrencies as a hole... Thanks!!!
> >>
> >> Anyway, I am unable to compile libcoin under my Ubuntu 11.04. At this
> >> machine, I have compiled and running Bitcoin (from sources), Namecoin,
> >> Devcoin, Litecoin, IXcoin and I0coin, all from sources but, when I try to
> >> compile libcoin, I got:
> >>
> >>
> >> user@desk:~/libcoin$ ./configure
> >> -- The C compiler identification is GNU
> >> -- The CXX compiler identification is GNU
> >> -- Check for working C compiler: /usr/bin/gcc
> >> -- Check for working C compiler: /usr/bin/gcc -- works
> >> -- Detecting C compiler ABI info
> >> -- Detecting C compiler ABI info - done
> >> -- Check for working CXX compiler: /usr/bin/c++
> >> -- Check for working CXX compiler: /usr/bin/c++ -- works
> >> -- Detecting CXX compiler ABI info
> >> -- Detecting CXX compiler ABI info
Re: [Bitcoin-development] Announcement: libcoin
Just copied your bitcoin.conf file to my system and the server connects just
fine to RPC on 10332
and I get using curl:
MacGronager:bin gronager$ curl --data-binary '{"jsonrpc": "2.0",
"id":"curltest", "method": "getblockcount", "params": [] }' -H 'Content-Type:
application/json' http://127.0.0.1:10332
{"jsonrpc":"2.0","result":168299,"error":null,"id":"curltest"}
Didn't do a retest on linux, but I am quite certain that it works there well as
I had it running for weeks on port 9332 on amazon.
However, the "port" parameter will not work
> ...
> bind(12, {sa_family=AF_INET, sin_port=htons(8333),
> sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
> ...
and as you can see it connects to 8333 - that for the bitcoin protocol.
I havn't implemented "port" (have a look at the possible options in
bitcoind.cpp). It was not on the official help list in bitcoind 0.4.0 (see
init.cpp or do a bitcoin/bitcoind -help). But, I can implement it over the
weekend if your need it.
I also tested the bitcoind --rpcport=10332 and it worked too using the
commandline - both running as server and client.
/M
> I already tried:
>
> /usr/local/bin/bitcoind --rpcport 10332
> /usr/local/bin/bitcoind --rpcport=10332
>
> Without success...
>
> Thanks again!
> Thiago
>
> 2012/2/24 Michael Grønager
> Hi Thiago,
>
> Forgot to comment on the two latter:
>
> > $ bitcoind getaccountaddress ""
> > HTTP error code: 401
> > Error: couldn't parse reply from server
> >
> > $ bitcoind listaccounts
> > HTTP error code: 401
> > Error: couldn't parse reply from server
> >
>
> 401 = permission denied - you need to setup username / password either on the
> commandline or in the bicoin.conf file to access those commands...
>
> See in the bitcoind.cpp file for commands that you can use with and without
> auth...
>
> Those that contains an "auth" requires auth:
>
> server.registerMethod(method_ptr(new GetBalance(wallet)), auth);
>
> As opposed to:
>
> server.registerMethod(method_ptr(new GetInfo(node)));
>
> auth is defined by:
>
> Auth auth(rpc_user, rpc_pass); // if rpc_user and rpc_pass are not set,
> all authenticated methods becomes disallowed.
>
> so you just experience the case explained in the comment ;) I admit that the
> output could be more readable, though!
>
> /M
>
>
> >
> > Any tips?! lol
> >
> > Thanks!
> > Thiago
> >
> > 2012/2/23 Martinx - ジェームズ
> > AWESOME!!!
> >
> > I can compile libcoin at my Ubuntu 11.10... I just need to install:
> >
> > sudo aptitude install libboost1.46-all-dev
> >
> > ...alongside with another already installed dependencies, and now it works!!
> >
> > Thank you!
> > Thiago
> >
> > 2012/2/23 Michael Grønager
> > Hi Martinx,
> >
> > Another note:
> >
> > boost 1.42 and openssl 1.0 has a conflict (you will see it when you try to
> > compile coinHTTP with that specific combination: sslv2 has been removed
> > from openssl, but boost still references it.)
> >
> > You should do a :
> >
> > sudo apt-get upgrade libboost-dev-all
> >
> > to get the 1.46.1 library
> >
> > /M
> >
> >
> > On 23/02/2012, at 18:31, Martinx - ジェームズ wrote:
> >
> >> Hi Michael!
> >>
> >> Thank you for libcoin! It is a awesome evolution for Bitcoin and for the
> >> CryptoCurrencies as a hole... Thanks!!!
> >>
> >> Anyway, I am unable to compile libcoin under my Ubuntu 11.04. At this
> >> machine, I have compiled and running Bitcoin (from sources), Namecoin,
> >> Devcoin, Litecoin, IXcoin and I0coin, all from sources but, when I try to
> >> compile libcoin, I got:
> >>
> >>
> >> user@desk:~/libcoin$ ./configure
> >> -- The C compiler identification is GNU
> >> -- The CXX compiler identification is GNU
> >> -- Check for working C compiler: /usr/bin/gcc
> >> -- Check for working C compiler: /usr/bin/gcc -- works
> >> -- Detecting C compiler ABI info
> >> -- Detecting C compiler ABI info - done
> >> -- Check for working CXX compiler: /usr/bin/c++
> >> -- Check for working CXX compiler: /usr/bin/c++ -- works
> >> -- Detecting CXX compiler ABI info
> >> -- Detecting CXX compiler ABI info - done
> >> -- Looking for include fil
Re: [Bitcoin-development] Announcement: libcoin
Hi Thiago, Forgot to comment on the two latter: > $ bitcoind getaccountaddress "" > HTTP error code: 401 > Error: couldn't parse reply from server > > $ bitcoind listaccounts > HTTP error code: 401 > Error: couldn't parse reply from server > 401 = permission denied - you need to setup username / password either on the commandline or in the bicoin.conf file to access those commands... See in the bitcoind.cpp file for commands that you can use with and without auth... Those that contains an "auth" requires auth: server.registerMethod(method_ptr(new GetBalance(wallet)), auth); As opposed to: server.registerMethod(method_ptr(new GetInfo(node))); auth is defined by: Auth auth(rpc_user, rpc_pass); // if rpc_user and rpc_pass are not set, all authenticated methods becomes disallowed. so you just experience the case explained in the comment ;) I admit that the output could be more readable, though! /M > > Any tips?! lol > > Thanks! > Thiago > > 2012/2/23 Martinx - ジェームズ > AWESOME!!! > > I can compile libcoin at my Ubuntu 11.10... I just need to install: > > sudo aptitude install libboost1.46-all-dev > > ...alongside with another already installed dependencies, and now it works!! > > Thank you! > Thiago > > 2012/2/23 Michael Grønager > Hi Martinx, > > Another note: > > boost 1.42 and openssl 1.0 has a conflict (you will see it when you try to > compile coinHTTP with that specific combination: sslv2 has been removed from > openssl, but boost still references it.) > > You should do a : > > sudo apt-get upgrade libboost-dev-all > > to get the 1.46.1 library > > /M > > > On 23/02/2012, at 18:31, Martinx - ジェームズ wrote: > >> Hi Michael! >> >> Thank you for libcoin! It is a awesome evolution for Bitcoin and for the >> CryptoCurrencies as a hole... Thanks!!! >> >> Anyway, I am unable to compile libcoin under my Ubuntu 11.04. At this >> machine, I have compiled and running Bitcoin (from sources), Namecoin, >> Devcoin, Litecoin, IXcoin and I0coin, all from sources but, when I try to >> compile libcoin, I got: >> >> >> user@desk:~/libcoin$ ./configure >> -- The C compiler identification is GNU >> -- The CXX compiler identification is GNU >> -- Check for working C compiler: /usr/bin/gcc >> -- Check for working C compiler: /usr/bin/gcc -- works >> -- Detecting C compiler ABI info >> -- Detecting C compiler ABI info - done >> -- Check for working CXX compiler: /usr/bin/c++ >> -- Check for working CXX compiler: /usr/bin/c++ -- works >> -- Detecting CXX compiler ABI info >> -- Detecting CXX compiler ABI info - done >> -- Looking for include files CMAKE_HAVE_PTHREAD_H >> -- Looking for include files CMAKE_HAVE_PTHREAD_H - found >> -- Looking for pthread_create in pthreads >> -- Looking for pthread_create in pthreads - not found >> -- Looking for pthread_create in pthread >> -- Looking for pthread_create in pthread - found >> -- Found Threads: TRUE >> -- Looking for XOpenDisplay in >> /usr/lib/i386-linux-gnu/libX11.so;/usr/lib/i386-linux-gnu/libXext.so >> -- Looking for XOpenDisplay in >> /usr/lib/i386-linux-gnu/libX11.so;/usr/lib/i386-linux-gnu/libXext.so - found >> -- Looking for gethostbyname >> -- Looking for gethostbyname - found >> -- Looking for connect >> -- Looking for connect - found >> -- Looking for remove >> -- Looking for remove - found >> -- Looking for shmat >> -- Looking for shmat - found >> -- Looking for IceConnectionNumber in ICE >> -- Looking for IceConnectionNumber in ICE - found >> -- Found X11: /usr/lib/i386-linux-gnu/libX11.so >> -- Boost version: 1.42.0 >> -- Found the following Boost libraries: >> -- date_time >> -- regex >> -- filesystem >> -- system >> -- program_options >> -- thread >> -- Found OpenSSL: /usr/lib/libssl.so;/usr/lib/libcrypto.so >> -- Looking for Q_WS_X11 >> -- Looking for Q_WS_X11 - found >> -- Looking for Q_WS_WIN >> -- Looking for Q_WS_WIN - not found. >> -- Looking for Q_WS_QWS >> -- Looking for Q_WS_QWS - not found. >> -- Looking for Q_WS_MAC >> -- Looking for Q_WS_MAC - not found. >> -- Found Qt-Version 4.7.2 (using /usr/bin/qmake) >> -- Found wxWidgets: TRUE >> >> The build system is configured to install libraries to /usr/local/lib >> Your applications may not be able to find your installed libraries unless >> you: >>set your LD_LIBRARY_PATH (user specific) or >>update your ld.so configuration (system wi
Re: [Bitcoin-development] Announcement: libcoin
Hi Thiago
I had in mind using the JSON RPC 2.0 system.description standard command
instead of help, but I got sidetracked implementing it. Will look into it asap.
Thanks for noting!
/M
On 24/02/2012, at 03:17, Martinx - ジェームズ wrote:
> Hi Michael!
>
> I just run "bitcoind", from libcoin ("sudo make install") sources, with empty
> ~/.bitcoin directory and:
>
> Terminal 1: bitcoind # apparently okay
>
> Terminal 2:
>
> $ bitcoind getinfo # okay
> {
>"version" : 40001,
>"blocks" : 57733,
>"connections" : 8,
>"difficulty" : 11.84622815,
>"testnet" : false
> }
>
> # sleep a couple minutes
>
> $ bitcoind getinfo # ok
> {
>"version" : 40001,
>"blocks" : 67527,
>"connections" : 8,
>"difficulty" : 45.38582234,
>"testnet" : false
> }
>
>
> But...
>
>
> $ bitcoind help
> HTTP error code: 404
> JSON RPC Error code: -36001
> Method not found.
>
> $ bitcoind getaccountaddress ""
> HTTP error code: 401
> Error: couldn't parse reply from server
>
> $ bitcoind listaccounts
> HTTP error code: 401
> Error: couldn't parse reply from server
>
>
> Any tips?! lol
>
> Thanks!
> Thiago
>
> 2012/2/23 Martinx - ジェームズ
> AWESOME!!!
>
> I can compile libcoin at my Ubuntu 11.10... I just need to install:
>
> sudo aptitude install libboost1.46-all-dev
>
> ...alongside with another already installed dependencies, and now it works!!
>
> Thank you!
> Thiago
>
> 2012/2/23 Michael Grønager
> Hi Martinx,
>
> Another note:
>
> boost 1.42 and openssl 1.0 has a conflict (you will see it when you try to
> compile coinHTTP with that specific combination: sslv2 has been removed from
> openssl, but boost still references it.)
>
> You should do a :
>
> sudo apt-get upgrade libboost-dev-all
>
> to get the 1.46.1 library
>
> /M
>
>
> On 23/02/2012, at 18:31, Martinx - ジェームズ wrote:
>
>> Hi Michael!
>>
>> Thank you for libcoin! It is a awesome evolution for Bitcoin and for the
>> CryptoCurrencies as a hole... Thanks!!!
>>
>> Anyway, I am unable to compile libcoin under my Ubuntu 11.04. At this
>> machine, I have compiled and running Bitcoin (from sources), Namecoin,
>> Devcoin, Litecoin, IXcoin and I0coin, all from sources but, when I try to
>> compile libcoin, I got:
>>
>>
>> user@desk:~/libcoin$ ./configure
>> -- The C compiler identification is GNU
>> -- The CXX compiler identification is GNU
>> -- Check for working C compiler: /usr/bin/gcc
>> -- Check for working C compiler: /usr/bin/gcc -- works
>> -- Detecting C compiler ABI info
>> -- Detecting C compiler ABI info - done
>> -- Check for working CXX compiler: /usr/bin/c++
>> -- Check for working CXX compiler: /usr/bin/c++ -- works
>> -- Detecting CXX compiler ABI info
>> -- Detecting CXX compiler ABI info - done
>> -- Looking for include files CMAKE_HAVE_PTHREAD_H
>> -- Looking for include files CMAKE_HAVE_PTHREAD_H - found
>> -- Looking for pthread_create in pthreads
>> -- Looking for pthread_create in pthreads - not found
>> -- Looking for pthread_create in pthread
>> -- Looking for pthread_create in pthread - found
>> -- Found Threads: TRUE
>> -- Looking for XOpenDisplay in
>> /usr/lib/i386-linux-gnu/libX11.so;/usr/lib/i386-linux-gnu/libXext.so
>> -- Looking for XOpenDisplay in
>> /usr/lib/i386-linux-gnu/libX11.so;/usr/lib/i386-linux-gnu/libXext.so - found
>> -- Looking for gethostbyname
>> -- Looking for gethostbyname - found
>> -- Looking for connect
>> -- Looking for connect - found
>> -- Looking for remove
>> -- Looking for remove - found
>> -- Looking for shmat
>> -- Looking for shmat - found
>> -- Looking for IceConnectionNumber in ICE
>> -- Looking for IceConnectionNumber in ICE - found
>> -- Found X11: /usr/lib/i386-linux-gnu/libX11.so
>> -- Boost version: 1.42.0
>> -- Found the following Boost libraries:
>> -- date_time
>> -- regex
>> -- filesystem
>> -- system
>> -- program_options
>> -- thread
>> -- Found OpenSSL: /usr/lib/libssl.so;/usr/lib/libcrypto.so
>> -- Looking for Q_WS_X11
>> -- Looking for Q_WS_X11 - found
>> -- Looking for Q_WS_WIN
>> -- Looking for Q_WS_WIN - not found.
>> -- Looking for Q_WS_QWS
>> -- Looking for Q_WS_QWS - not found.
>> -- Looking for Q_WS_MAC
>> -- Looking for Q_WS_MAC - not found.
&
Re: [Bitcoin-development] Announcement: libcoin
t._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned > int)]+0xf): undefined reference to `BN_init' > Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned > int)]+0x1e): undefined reference to `BN_copy' > Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned > int)]+0x47): undefined reference to `BN_clear_free' > Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned > int)]+0xcb): undefined reference to `BN_clear_free' > ../../lib/libcoin.a(Script.o): In function `operator!=(CBigNum const&, > CBigNum const&)': > Script.cpp:(.text._ZneRK7CBigNumS1_[operator!=(CBigNum const&, CBigNum > const&)]+0x14): undefined reference to `BN_cmp' > ../../lib/libcoin.a(Script.o): In function `operator>(CBigNum const&, CBigNum > const&)': > Script.cpp:(.text._ZgtRK7CBigNumS1_[operator>(CBigNum const&, CBigNum > const&)]+0x14): undefined reference to `BN_cmp' > ../../lib/libcoin.a(Script.o): In function `uint256 > Hash<__gnu_cxx::__normal_iterator std::allocator > > >(__gnu_cxx::__normal_iterator char*, std::vector > >, > __gnu_cxx::__normal_iterator std::allocator > >)': > Script.cpp:(.text._Z4HashIN9__gnu_cxx17__normal_iteratorIPhSt6vectorIhSaIhE7uint256T_S8_[uint256 > Hash<__gnu_cxx::__normal_iterator std::allocator > > >(__gnu_cxx::__normal_iterator char*, std::vector > >, > __gnu_cxx::__normal_iterator std::allocator > >)]+0x6d): undefined reference to `SHA256' > Script.cpp:(.text._Z4HashIN9__gnu_cxx17__normal_iteratorIPhSt6vectorIhSaIhE7uint256T_S8_[uint256 > Hash<__gnu_cxx::__normal_iterator std::allocator > > >(__gnu_cxx::__normal_iterator char*, std::vector > >, > __gnu_cxx::__normal_iterator std::allocator > >)]+0xb8): undefined reference to `SHA256' > collect2: ld returned 1 exit status > make[2]: *** [bin/bitcoind] Error 1 > make[1]: *** [applications/bitcoind/CMakeFiles/app_bitcoind.dir/all] Error 2 > make: *** [all] Error 2 > - > > What can I do?! > > Best, > Thiago > > > On 1 February 2012 12:18, Michael Grønager wrote: > Dear Bitcoiners, > > libcoin is now in a state ready for its first release, which I would like to > share with you! > > === libcoin is a crypto currency library based on the bitcoin/bitcoin > "Satoshi" client. === > > Copenhagen, Denmark - 1st February 2012 Ceptacle announces the release of the > first version of the crypto currency library "libcoin" based on the > bitcoin/bitcoin "Satoshi" client. > > libcoin also maintains a version of bitcoind that is a 100% compatible > drop-in replacement of the bitcoin/bitcoind client: You can use it on the > same computer on the same files and you can call it with the same scripts. > And you can easily extend it without touching the basic bitcoin source files. > > The libcoin/bitcoind client downloads the entire block chain 3.5 times faster > than the bitcoin/bitcoind client. This is less than 90 minutes on a modern > laptop! > > In libcoin, the Satoshi client code has been completely refactored, properly > encapsulating classes, removing all globals, moving from threads and mutexes > to a pure asynchronous approach. Functionalities have been divided into > logical units and libraries, minimizing dependencies for e.g. thin clients. > > libcoin is chain agnostic, all chain (bitcoin, testnet, namecoin, litecoin, > ...) specific settings are maintained from a single class (Chain) and hence > experiments with chain settings, mining, security and digital currencies for > research and educational purposes are easily accessible. See the ponzicoin > example for how you define your own chain. > > The build system of libcoin is based on CMake and supports builds of static > and dynamic libraries on Linux, Mac OS X, and Windows. > > The libcoin license is LGPL v. 3. This mean that you can use it in open > source as well as in commercial projects, but improvements should go back > into the libcoin library. > > == > > Read more on libcoin on: http://github.com/ceptacle/libcoin/wiki > > Join libcoin on twitter: http://twitter.com/libcoin > > Download "libcoin Satoshi release": > http://github.com/ceptacle/libcoin/zipball/v0.4.0.1 > > Best regards, > > Michael Gronager, PhD > Director, Ceptacle > Jens Juels Gade 33 > 2100 Copenhagen E > Mobile: +45 31 45 14 01 > E-mail: grona...@ceptacle.com > Web: http://www.ceptacle.com/ > > > -- > Keep Your Develop
Re: [Bitcoin-development] Announcement: libcoin
nsigned int)': > Script.cpp:(.text._ZlsRK7CBigNumj[operator<<(CBigNum const&, unsigned > int)]+0x16): undefined reference to `BN_init' > Script.cpp:(.text._ZlsRK7CBigNumj[operator<<(CBigNum const&, unsigned > int)]+0x2c): undefined reference to `BN_lshift' > Script.cpp:(.text._ZlsRK7CBigNumj[operator<<(CBigNum const&, unsigned > int)]+0xad): undefined reference to `BN_clear_free' > ../../lib/libcoin.a(Script.o): In function `operator>>(CBigNum const&, > unsigned int)': > Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned > int)]+0xf): undefined reference to `BN_init' > Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned > int)]+0x1e): undefined reference to `BN_copy' > Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned > int)]+0x47): undefined reference to `BN_clear_free' > Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned > int)]+0xcb): undefined reference to `BN_clear_free' > ../../lib/libcoin.a(Script.o): In function `operator!=(CBigNum const&, > CBigNum const&)': > Script.cpp:(.text._ZneRK7CBigNumS1_[operator!=(CBigNum const&, CBigNum > const&)]+0x14): undefined reference to `BN_cmp' > ../../lib/libcoin.a(Script.o): In function `operator>(CBigNum const&, CBigNum > const&)': > Script.cpp:(.text._ZgtRK7CBigNumS1_[operator>(CBigNum const&, CBigNum > const&)]+0x14): undefined reference to `BN_cmp' > ../../lib/libcoin.a(Script.o): In function `uint256 > Hash<__gnu_cxx::__normal_iterator std::allocator > > >(__gnu_cxx::__normal_iterator char*, std::vector > >, > __gnu_cxx::__normal_iterator std::allocator > >)': > Script.cpp:(.text._Z4HashIN9__gnu_cxx17__normal_iteratorIPhSt6vectorIhSaIhE7uint256T_S8_[uint256 > Hash<__gnu_cxx::__normal_iterator std::allocator > > >(__gnu_cxx::__normal_iterator char*, std::vector > >, > __gnu_cxx::__normal_iterator std::allocator > >)]+0x6d): undefined reference to `SHA256' > Script.cpp:(.text._Z4HashIN9__gnu_cxx17__normal_iteratorIPhSt6vectorIhSaIhE7uint256T_S8_[uint256 > Hash<__gnu_cxx::__normal_iterator std::allocator > > >(__gnu_cxx::__normal_iterator char*, std::vector > >, > __gnu_cxx::__normal_iterator std::allocator > >)]+0xb8): undefined reference to `SHA256' > collect2: ld returned 1 exit status > make[2]: *** [bin/bitcoind] Error 1 > make[1]: *** [applications/bitcoind/CMakeFiles/app_bitcoind.dir/all] Error 2 > make: *** [all] Error 2 > - > > What can I do?! > > Best, > Thiago > > > On 1 February 2012 12:18, Michael Grønager wrote: > Dear Bitcoiners, > > libcoin is now in a state ready for its first release, which I would like to > share with you! > > === libcoin is a crypto currency library based on the bitcoin/bitcoin > "Satoshi" client. === > > Copenhagen, Denmark - 1st February 2012 Ceptacle announces the release of the > first version of the crypto currency library "libcoin" based on the > bitcoin/bitcoin "Satoshi" client. > > libcoin also maintains a version of bitcoind that is a 100% compatible > drop-in replacement of the bitcoin/bitcoind client: You can use it on the > same computer on the same files and you can call it with the same scripts. > And you can easily extend it without touching the basic bitcoin source files. > > The libcoin/bitcoind client downloads the entire block chain 3.5 times faster > than the bitcoin/bitcoind client. This is less than 90 minutes on a modern > laptop! > > In libcoin, the Satoshi client code has been completely refactored, properly > encapsulating classes, removing all globals, moving from threads and mutexes > to a pure asynchronous approach. Functionalities have been divided into > logical units and libraries, minimizing dependencies for e.g. thin clients. > > libcoin is chain agnostic, all chain (bitcoin, testnet, namecoin, litecoin, > ...) specific settings are maintained from a single class (Chain) and hence > experiments with chain settings, mining, security and digital currencies for > research and educational purposes are easily accessible. See the ponzicoin > example for how you define your own chain. > > The build system of libcoin is based on CMake and supports builds of static > and dynamic libraries on Linux, Mac OS X, and Windows. > > The libcoin license is LGPL v. 3. This mean that you can use it in open > source as well as in commercial projects, but improvements should go back > into the libcoin library. > > == >
Re: [Bitcoin-development] Announcement: libcoin
to `BN_init' > Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned > int)]+0x1e): undefined reference to `BN_copy' > Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned > int)]+0x47): undefined reference to `BN_clear_free' > Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&, unsigned > int)]+0xcb): undefined reference to `BN_clear_free' > ../../lib/libcoin.a(Script.o): In function `operator!=(CBigNum const&, > CBigNum const&)': > Script.cpp:(.text._ZneRK7CBigNumS1_[operator!=(CBigNum const&, CBigNum > const&)]+0x14): undefined reference to `BN_cmp' > ../../lib/libcoin.a(Script.o): In function `operator>(CBigNum const&, CBigNum > const&)': > Script.cpp:(.text._ZgtRK7CBigNumS1_[operator>(CBigNum const&, CBigNum > const&)]+0x14): undefined reference to `BN_cmp' > ../../lib/libcoin.a(Script.o): In function `uint256 > Hash<__gnu_cxx::__normal_iterator std::allocator > > >(__gnu_cxx::__normal_iterator char*, std::vector > >, > __gnu_cxx::__normal_iterator std::allocator > >)': > Script.cpp:(.text._Z4HashIN9__gnu_cxx17__normal_iteratorIPhSt6vectorIhSaIhE7uint256T_S8_[uint256 > Hash<__gnu_cxx::__normal_iterator std::allocator > > >(__gnu_cxx::__normal_iterator char*, std::vector > >, > __gnu_cxx::__normal_iterator std::allocator > >)]+0x6d): undefined reference to `SHA256' > Script.cpp:(.text._Z4HashIN9__gnu_cxx17__normal_iteratorIPhSt6vectorIhSaIhE7uint256T_S8_[uint256 > Hash<__gnu_cxx::__normal_iterator std::allocator > > >(__gnu_cxx::__normal_iterator char*, std::vector > >, > __gnu_cxx::__normal_iterator std::allocator > >)]+0xb8): undefined reference to `SHA256' > collect2: ld returned 1 exit status > make[2]: *** [bin/bitcoind] Error 1 > make[1]: *** [applications/bitcoind/CMakeFiles/app_bitcoind.dir/all] Error 2 > make: *** [all] Error 2 > - > > What can I do?! > > Best, > Thiago > > > On 1 February 2012 12:18, Michael Grønager wrote: > Dear Bitcoiners, > > libcoin is now in a state ready for its first release, which I would like to > share with you! > > === libcoin is a crypto currency library based on the bitcoin/bitcoin > "Satoshi" client. === > > Copenhagen, Denmark - 1st February 2012 Ceptacle announces the release of the > first version of the crypto currency library "libcoin" based on the > bitcoin/bitcoin "Satoshi" client. > > libcoin also maintains a version of bitcoind that is a 100% compatible > drop-in replacement of the bitcoin/bitcoind client: You can use it on the > same computer on the same files and you can call it with the same scripts. > And you can easily extend it without touching the basic bitcoin source files. > > The libcoin/bitcoind client downloads the entire block chain 3.5 times faster > than the bitcoin/bitcoind client. This is less than 90 minutes on a modern > laptop! > > In libcoin, the Satoshi client code has been completely refactored, properly > encapsulating classes, removing all globals, moving from threads and mutexes > to a pure asynchronous approach. Functionalities have been divided into > logical units and libraries, minimizing dependencies for e.g. thin clients. > > libcoin is chain agnostic, all chain (bitcoin, testnet, namecoin, litecoin, > ...) specific settings are maintained from a single class (Chain) and hence > experiments with chain settings, mining, security and digital currencies for > research and educational purposes are easily accessible. See the ponzicoin > example for how you define your own chain. > > The build system of libcoin is based on CMake and supports builds of static > and dynamic libraries on Linux, Mac OS X, and Windows. > > The libcoin license is LGPL v. 3. This mean that you can use it in open > source as well as in commercial projects, but improvements should go back > into the libcoin library. > > == > > Read more on libcoin on: http://github.com/ceptacle/libcoin/wiki > > Join libcoin on twitter: http://twitter.com/libcoin > > Download "libcoin Satoshi release": > http://github.com/ceptacle/libcoin/zipball/v0.4.0.1 > > Best regards, > > Michael Gronager, PhD > Director, Ceptacle > Jens Juels Gade 33 > 2100 Copenhagen E > Mobile: +45 31 45 14 01 > E-mail: grona...@ceptacle.com > Web: http://www.ceptacle.com/ > > > -- > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Micro
Re: [Bitcoin-development] BIP-13
Hi Gavin / Luke, BIP-13 again... I started to implement a bitfield based parsing of the version byte using the description I got from Luke, but I then discovered that it does not hold: Network class: 00xx - main network 01xx - reserved 10xx - reserved 11xx - test network Network: xx00 - bitcoin xx01 - reserved xx10 - OTHER (next octet) xx11 - Namecoin Network specific: 000y - PubKeyHash 001y - reserved 010y - p2sh 011y - public key (raw) 100y - signature 101y - reserved 110y - private key (raw) 111y - OTHER (next octet) However, the definitions en base58.h are: PUBKEY_ADDRESS = 0, () SCRIPT_ADDRESS = 5, (0101) PUBKEY_ADDRESS_TEST = 111, (0110) !!! SCRIPT_ADDRESS_TEST = 196, (11000100) !!! [as a side note litecoin is 48 (0011) and namecoin is 52 (00110100)] So there is no logic ?? I have searched the mailing list and the forum for discussions on this but found it hard to find any. If I overlooked something please direct me. Cheers, M PS: I have said so before, but it would *really* be nice if discussions / conclusions / irc-summaries were taking place at one place - e.g. at the bitcoin-dev mailing list, not at 5-10 different threads in bitcointalk or in bip notes or solely on IRC... On 20/02/2012, at 18:17, Gavin Andresen wrote: > RE: > > base58-encode: [one-byte network ID][20-byte hash][one-byte address > > class][3-byte checksum] > > How will the code distinguish between the old scheme: > [one-byte-version][20-byte-hash][4-byte-checksum] > and the new? > > 1 in 256 old addresses will have a first-byte-of-checksum that matches the > new address class; I guess the code would do something like: > > a) If the 4-byte checksum matches, then assume it is a singlesig address (1 > in 2^32 multisig addresses will incorrectly match) > b) If the one-byte-address-class and 3-byte checksum match, then it is a > valid p2sh > c) Otherwise, invalid address > > The 1 in 2^32 multisig addresses also being valid singlesig addresses makes > me think this scheme won't work-- an attacker willing to generate 8 billion > or so ECDSA keys could generate a single/multisig collision. I'm not sure > how that could be leveraged to their advantage, but I bet they'd find a way. > > RE: should it be a BIP: The BIP process is described in BIP 0001, and you're > following it perfectly so far: > > 1) Post a rough draft of the idea here to see if there's any chance it'll be > adopted > 2) Assuming a positive response and no major flaws: write up a draft BIP > 3) Post the draft BIP here, where it can be picked apart. > 4) Assuming no major flaws, ask the BIP editor (Amir) for a BIP number > > I'd also encourage you to actually implement your idea between steps 3 and 4. > But in this particular case, I think an attacker being able to create > singlesig/p2sh address collisions counts as a major flaw. > > -- > -- > Gavin Andresen Michael Gronager, PhD Director, Ceptacle Jens Juels Gade 33 2100 Copenhagen E Mobile: +45 31 45 14 01 E-mail: grona...@ceptacle.com Web: http://www.ceptacle.com/ -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] BitcoinQt eating 100% CPU
Hi Wladimir / others, I just downloaded the latest (0.6 rc1) source of bitcoin-qt and built it using qt-creator on MacOSX 10.7.3. Nice and easy experience, even though I had to change BDB version to 5.1 ;) However, when running it, it is using 100% CPU (after initial block chain download that is...) * All activity in debug.log seems normal (blocks/txes/addresses are processes and accepted etc) so it is not stuck (at least not in the MessageThread) * Sampling the process shows that the majority of time in each thread is used for: ** __semwait_signal ** kevent ** __select ** mach_msg_trap ** boost::date_time::micro_sec_clock None of this would usually alert me - sleeping and waiting for conditions should not consume CPU, the only issue seems to be the last line which is called from qtipcserver.cpp line 31: if(mq->timed_receive(&strBuf, sizeof(strBuf), nSize, nPriority, d)) As I see it this should not consume cpu either, but, it is the only thing that seems a bit strange.. Have you seen this before? /M -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP-13
> How will the code distinguish between the old scheme: > [one-byte-version][20-byte-hash][4-byte-checksum] > and the new? > > 1 in 256 old addresses will have a first-byte-of-checksum that matches the > new address class; I guess the code would do something like: > > a) If the 4-byte checksum matches, then assume it is a singlesig address (1 > in 2^32 multisig addresses will incorrectly match) > b) If the one-byte-address-class and 3-byte checksum match, then it is a > valid p2sh > c) Otherwise, invalid address Exactly! > > The 1 in 2^32 multisig addresses also being valid singlesig addresses makes > me think this scheme won't work-- an attacker willing to generate 8 billion > or so ECDSA keys could generate a single/multisig collision. I'm not sure > how that could be leveraged to their advantage, but I bet they'd find a way. Nope - its almost like calling the version:0+5 possible collision with new evil, say "ponzicoin" with version=5 a possible flaw that could be exploited... And you can already create non-existing addresses with a matching checksum... > I'd also encourage you to actually implement your idea between steps 3 and 4. > But in this particular case, I think an attacker being able to create > singlesig/p2sh address collisions counts as a major flaw. I will rest my case, not due to the "flaw", but I got some info on the bitfields of the "version" (thanks Luke!) - this makes the +5 less arbitrary, however, I don't think the bitfield interpretation is that well known, so there might already be "version"-collisions...: Network class: 00xx - main network 01xx - reserved 10xx - reserved 11xx - test network Network: xx00 - bitcoin xx01 - reserved xx10 - OTHER (next octet) xx11 - Namecoin Network specific: 000y - PubKeyHash 001y - reserved 010y - p2sh 011y - public key (raw) 100y - signature 101y - reserved 110y - private key (raw) 111y - OTHER (next octet) y = 0/1 depending on aesthetics (I guess to force the address to be either 1 or 3). This also opens up for extensions - (if xx10 or 111x) the next byte will be part of the version. /M > > -- > -- > Gavin Andresen -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP-13
> >> The "version" portion of the address has so far been labeled "network id", >> and indicates from which network and which chain the address can be used >> for. > > Where do you see this? It has always been "version" as far as I am aware, and > we discussed formalizing the details of the bits in it a few months back. > In any case, it was certainly originally intended as "version" as can be > observed in Satoshi's reference implementation. See: https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses And the attached graphics - here it is defined as network byte and network id. Anyway - can probably live with some bit level subdivision into network id and address class. /M -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] BIP-13
Just posted this on the wiki BIP-13 discussion - should I make it into a BIP of its own ? --- The "version" portion of the address has so far been labeled "network id", and indicates from which network and which chain the address can be used for. I think that this change from network id to version is much more fundamental and should not just be squeezed in along with bip16/17. The right way to do this is to structure the bitcoin address into: base58-encode: [one-byte network ID][20-byte hash][one-byte address class][3-byte checksum] This will move the possibility of using a faulty address from 1 to 4bill to 1 to 24mio. Recall that for most other payment systems this checksum is 1 to 9! So it should be sufficient. An old client will then render the new addresses as useless and they will still maintain their old familiar 1xxx look - the whole point in multisig is that it should not be a matter of the paying party to worry about securing wallet of the receiver, hence he should not be bothered with a new "3" kind of address now... --Michael Gronager/libcoin 10:49, 20 February 2012 (GMT) -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] off-topic: bitcoin-forum...
Thanks! "required 5 posts and 4 hours" Well, that is not so easy if you cannot post ;) I will apply for whitelisting - strange policy though... /M On 19/02/2012, at 17:42, Harald Schilly wrote: > On Sun, Feb 19, 2012 at 17:38, Michael Gronager wrote: >> In the expectation of a embarrassingly simple answer... > > you probably need to be whitelisted, but i'm not sure. > https://bitcointalk.org/index.php?topic=15911.0 > > h Michael Gronager, PhD Director, Ceptacle Jens Juels Gade 33 2100 Copenhagen E Mobile: +45 31 45 14 01 E-mail: grona...@ceptacle.com Web: http://www.ceptacle.com/ -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] coinexplorer - a local "blockexplorer"
I have just uploaded a new application to libcoin: "coinexplorer" It enables queries similar to that of blockexplorer.com, but locally on your own chain. coinexplorer builds on a new library addition: coinStat, that is a collection of classes for gathering and querying the block chain for other information than the ones used directly by the Node. coinexplorer uses the HTTP GET feature of the coinHTTP/Server class to enable a simple search webpage, so you can do block searches by either commandline: bitcoind search or simply by pointing you browser at http://localhost:8332 I apologize for the rudimentary interface, but I am not really a javascript/html5 savvy... So a more modern interface is left as an exercise for those who are. You will find coinexplorer in the latest git: https://github.com/ceptacle/libcoin Cheers, Michael Michael Gronager, PhD Director, Ceptacle Jens Juels Gade 33 2100 Copenhagen E Mobile: +45 31 45 14 01 E-mail: grona...@ceptacle.com Web: http://www.ceptacle.com/ -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.5.2 tag in github ??
Hi Aidan, Thanks, and the number is still 140700 - do we have a policy / logic on adding new checkpoints ? It seems to me that the number could easily be bumped to 16 by now ? Cheers, Michael On 03/02/2012, at 10:52, Aidan Thornton wrote: > On Fri, Feb 3, 2012 at 9:22 AM, Michael Grønager > wrote: >> Hi Gavin, others? >> >> I am trying to redo the performance test of the libcoin client against the >> 0.5.2 Satoshi client, that I have learned also have received quite some >> improvements in speed since 0.4.0 (e.g. from not verifying signatures on >> early blocks). >> >> However, I cannot find any tag with v0.5.2 in github: >> https://github.com/bitcoin/bitcoin/tags > > I think that tag's in > https://gitorious.org/+bitcoin-stable-developers/bitcoin/bitcoind-stable > - a certain amount of developer politics seems to be involved, and > v0.5.2 may not have been pushed to the official github repository. Michael Gronager, PhD Director, Ceptacle Jens Juels Gade 33 2100 Copenhagen E Mobile: +45 31 45 14 01 E-mail: grona...@ceptacle.com Web: http://www.ceptacle.com/ -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Announcement: libcoin
> Hello Michael,
>
> I'm impressed by your refactorings, and hope some of them can make it into
> the Satoshi codebase.
Thanks:)
> I am however not sure what you've said above is safe. In particular, how do
> you guarantee that no other thread modifies the blockchain structure while
> you are performing your query on it? Does the query code operate on a const
> copy of the structure, or is there guaranteed only one thread accessing it?
The BlockChain class encapsulates all access to the blockchain and only give
you access to certain restricted queries on the chain. Actually that was the
case already in the satoshi client, I have only tried to formalize and
encapsulate these queries in the code instead of having all the code poking
around directly in the database and the blockfile.
I should note that the database still keeps a mutex to protect reads from
writes.
I agree that constness alone does not guarantee thread safety, it is one of the
things to use to get there. Great care should be taken not to read a value that
is being changed at the same time, at least if that will render the result
unusable.
The list of allowed queries are the const public methods of BlockChain. Some
examples :
1.bool isSpent(Coin coin) const;
2.int getNumSpent(uint256 hash) const ;
3.uint256 spentIn(Coin coin) const;
/// Check if the hash of a block belongs to a block in the main chain:
4.bool isInMainChain(const uint256 hash) const;
/// Get the best height
5.int getBestHeight() const { return _bestIndex->nHeight; }
Or e.g.:
6.void getBlock(const uint256 hash, Block& block) const;
1-3. can be used to check if a COutPoint (now Coin) has been spent etc... This
will only generate sane results, even if the two threads are both active on the
same data structures.
Same goes for 4. and 6. copies a block from the block file to the Block&
provided so no issues here either.
I do, however, admit, that an extra review of all the public const methods
would be wise, to ensure that I have not overlooked something. I'll open an
issue on this and use a cold winter night on looking them over again.
Cheers,
Michael
>
> I've been thinking about moving to read-write locks that allow multiple
> threads reading the datastructure simultaneously, but removing the locking
> all together sounds wrong to me.
>
> --
> Pieter
Michael Gronager, PhD
Director, Ceptacle
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 45 14 01
E-mail: grona...@ceptacle.com
Web: http://www.ceptacle.com/
--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] 0.5.2 tag in github ??
Hi Gavin, others? I am trying to redo the performance test of the libcoin client against the 0.5.2 Satoshi client, that I have learned also have received quite some improvements in speed since 0.4.0 (e.g. from not verifying signatures on early blocks). However, I cannot find any tag with v0.5.2 in github: https://github.com/bitcoin/bitcoin/tags Am I missing something, or wasn't that release tagged ? What I am looking for in particular is the number "140700", the last block not to be verified - I can see this in: https://github.com/bitcoin/bitcoin/blob/master/src/checkpoints.cpp But I would like to be sure that this is also the number used in 0.5.2. Thanks, Michael -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] libcoin (HEAD) now supports boost < 1.47 - please test
Thanks for the patch and the detective work!
Enabling dynamic libs was on my TODO, but on the Redmond_OS_not_to_be_mentioned
you need to :
* prepend class definitions with __declspec(dllexport) when you compile the dll
* prepend class definitions with __declspec(dllimport) when you use the dll
I just love the way they spoil their developers...
I have the framework to automate this with CMake from a former project, but I
havn't tested it for libcoin yet, hence the static build. And well, iOS also
has this fetich for static libs.
I also recall another issue with dll's: If you define a global variable it is
shared between all executables using this dll. I have still a handful of
globals to clean out, namely those related to logging - I will do so, but it
has not yet been a top priority.
So, feel free to use dynamic libs on unix'es, but on windows it is .libs for a
little while longer.
Will fix the Qt stuff in CMake - thanks!
Cheers,
Michael
On 02/02/2012, at 17:30, Luke-Jr wrote:
> On Thursday, February 02, 2012 8:46:05 AM Michael Grønager wrote:
>> Please test and feed back.
>
> I found the problem: you are trying to use static libraries. Best practices
> are to use shared libraries (except for specific scenarios like universal
> "Linux" binaries) and most distros do not have static libraries installed by
> default.
>
> The coinQt stuff was also creating a problem.
>
> I am able to build with this patch:
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index dea37c4..b876881 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -352,7 +352,7 @@ ENDIF(BDB_FOUND)
> #Note: We need as a minimum Boost 1.47 to support the signal_set used in
> Server. A backup signal_set has been created, though.
> SET(Boost_NO_BOOST_CMAKE ON)
> SET(Boost_ADDITIONAL_VERSIONS "1.47" "1.47.0" "1.48" "1.48.0")
> -SET(Boost_USE_STATIC_LIBSON)
> +#SET(Boost_USE_STATIC_LIBSON)
> SET(Boost_USE_MULTITHREADED ON)
> SET(Boost_USE_STATIC_RUNTIMEOFF)
>
> @@ -804,9 +804,9 @@ SET(PKGCONFIG_FILES
> # libcoin-coinMine
> )
>
> -IF(QT4_FOUND)
> - SET(PKGCONFIG_FILES ${PKGCONFIG_FILES} libcoin-coinQt)
> -ENDIF(QT4_FOUND)
> +#IF(QT4_FOUND)
> +# SET(PKGCONFIG_FILES ${PKGCONFIG_FILES} libcoin-coinQt)
> +#ENDIF(QT4_FOUND)
>
> FOREACH(PKGCONFIG_FILE ${PKGCONFIG_FILES})
>
> CONFIGURE_FILE(${PROJECT_SOURCE_DIR}/packaging/pkgconfig/${PKGCONFIG_FILE}.pc.in
> diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
> index 0011392..67044d1 100644
> --- a/src/CMakeLists.txt
> +++ b/src/CMakeLists.txt
> @@ -19,9 +19,9 @@ FOREACH( mylibfolder
>
> ENDFOREACH()
>
> -IF (QT4_FOUND AND NOT ANDROID)
> -ADD_SUBDIRECTORY(coinQt)
> -ENDIF()
> +#IF (QT4_FOUND AND NOT ANDROID)
> +#ADD_SUBDIRECTORY(coinQt)
> +#ENDIF()
>
> IF(ANDROID)
> configure_file("${LIBCOIN_ANDROID_TEMPLATES}/Android.mk.src.in"
> "${CMAKE_CURRENT_BINARY_DIR}/Android.mk")
Michael Gronager, PhD
Director, Ceptacle
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 45 14 01
E-mail: grona...@ceptacle.com
Web: http://www.ceptacle.com/
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] libcoin (HEAD) now supports boost < 1.47 - please test
I have added a simplified fall back class to the boost::asio::signal_set. This should enable compilation on platforms with less than bleeding edge versions of Boost. Most notably most of the currently deployed Linux'es that use Boost 1.42. I also updated the root CMakeLists.txt to only require 1.42. It works for me, but I also recognize the fact that committers machines has some intrinsic magic that just makes things work, hiding actual errors for the them ;) Please test and feed back. Cheers, Michael Michael Gronager, PhD Director, Ceptacle Jens Juels Gade 33 2100 Copenhagen E Mobile: +45 31 45 14 01 E-mail: grona...@ceptacle.com Web: http://www.ceptacle.com/ -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Announcement: libcoin
I agree on your architectural considerations - and with libcoin you can have
several wallets in the same application ( and several RPC servers for that
matter). And ... they all use the same Node / blockchain.
You will also find the RPC server in libcoin blistering fast compared to the
Satoshi client. (It was actually what got me to write libcoin in the first
place...). The Satoshi client HTTP server executes all rpc commands in its own
thread, but to do so, it needs to stop the thread of the Node, even though the
command executed is just a query (i.e. not a SendTo), you hence have two
threads blocking each other and when they wait, you wait... In libcoin all the
query methods access the blockChain as a const object and they can hence safely
query it without intervening the work of the Node thread. The exception are the
SendTo methods that first query if a transaction can take place, then pushes it
to the work-queue of the Node thread and again exits immediately. The actual
execution then follows once the Node has finished its current tasks (e.g.
validating a block).
I have attached the code for a very simple one node, two wallet, libcoin client
below (~30 lines), and I have added it to the libcoin source as an example
(example name: extrawallets).
Once running, you can access your extra wallet using the RPC interface:
./extrawallet extragetbalance
And youy normal wallet by:
./extrawallet getbalance
I'll leave the generalization to an n-wallet gui application to the reader ;)
Cheers,
Michael
// The derived classes below are only to get other class names (using the auto
rpc name feature)
// I will put adding a "setName" method to the Method class on the todo.
class ExtraGetBalance : public GetBalance {
public:
ExtraGetBalance(Wallet& wallet) : GetBalance(wallet) {}
};
class ExtraSendToAddress : public GetBalance {
public:
ExtraSendToAddress(Wallet& wallet) : GetBalance(wallet) {}
};
int main(int argc, char* argv[])
{
logfile = CDB::dataDir(bitcoin.dataDirSuffix()) + "/debug.log";
Node node; // deafult chain is bitcoin
Wallet wallet(node, "wallet.dat"); // add the wallet
Wallet extra_wallet(node, "extra_wallet.dat"); // add the extra wallet
thread nodeThread(&Node::run, &node); // run this as a background thread
Server server;
// Register Server methods.
server.registerMethod(method_ptr(new Stop(server)));
// Register Node methods.
server.registerMethod(method_ptr(new GetBlockCount(node)));
server.registerMethod(method_ptr(new GetConnectionCount(node)));
server.registerMethod(method_ptr(new GetDifficulty(node)));
server.registerMethod(method_ptr(new GetInfo(node)));
// Register Wallet methods. - note that we don't have any auth, so anyone
(on localhost) can read your balance!
server.registerMethod(method_ptr(new GetBalance(wallet)));
server.registerMethod(method_ptr(new SendToAddress(wallet)),
Auth("username","password"));
server.registerMethod(method_ptr(new ExtraGetBalance(wallet)));
server.registerMethod(method_ptr(new ExtraSendToAddress(wallet)),
Auth("username","password"));
server.run();
node.shutdown();
nodeThread.join();
}
On 02/02/2012, at 00:50, grarpamp wrote:
>> However, I think perhaps the bitcoin project should be split into a library,
>> with a prototype client and the actual clients. This library facilitates
>> this.
>
> I'll be trying your implementation soon. And libbitcoin/subvertx too.
> Partly because they're also non-interpreted, and partly to what seems
> better architected...
>
> To the minimal extent of my understanding... I'd like to see wallet
> ops completely separated from background chain ops. ie: have
> a chain daemon doing it's thing, updating, verifying, etc. The
> generator doing it's thing. And a wallet app that can independently
> manage separate wallets in parallel, referencing the live chain files
> as needed. It seems a library would allow quality focus on the separate
> functions and let apps/ui's use the fn's as desired on top. Right now, it
> seems I have to run bitcoind and can only deal with one wallet at a time,
> having to stop it, deal with state issues, swap in a new wallet, start
> it, and repeat till illness ensues :( And when the chain is being processed
> hard by the daemon cpuwise, bitcoin RPC takes minutes to respond, if ever
> or errors out. If wallet ops or statistical queries on the chain need it for
> integrity or reading, a db checkpoint/lock/logroll could be implemented into
> the chain demon processes with a client lib api to trigger it as needed.
> Don't know, just saying.
>
> fyi... boost 1.48 and db 4.8.30 work fine with 0.5.2, 0.5.x, and master,
> you just need to compile and include it by hand if you want it and
> your package manager doesn't have it.
Michael Gronager, PhD
Director, Ceptacle
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 45 14 01
E-mail: grona...@ceptacle.com
Web: http://www.ceptacle.com/
-
Re: [Bitcoin-development] Announcement: libcoin
In the CMakeLists.txt file in the libcoin root find the lines regarding Boost - it says ... 1.48 ... Change that to 1.47 and try again. I suggest you first remove your CMakeCache.txt though... (the Qt stuff is most likely not the culprit) /M On 01/02/2012, at 18:37, Luke-Jr wrote: > On Wednesday, February 01, 2012 11:20:22 AM Michael Grønager wrote: >> OK - from your path it looks like linux. What version of Boost do you use. >> I require 1.47 or 1.48. - I will change that, but it is quite handy for >> signal_sets - will make an alternative scheme though. > > Upgrading to 1.47 did not change the error at all... :/ Michael Gronager, PhD Director, Ceptacle Jens Juels Gade 33 2100 Copenhagen E Mobile: +45 31 45 14 01 E-mail: grona...@ceptacle.com Web: http://www.ceptacle.com/ -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Announcement: libcoin
Just wrote it in another mail, but I am quite certain it is the boost version - you need 1.48 (or 1.47). /M On 01/02/2012, at 17:15, Luke-Jr wrote: > On Wednesday, February 01, 2012 10:58:28 AM Michael Grønager wrote: >> Your CMake cannot find boost - use ccmake or cmake-gui to help it with the >> location. > > I didn't see anything useful in ccmake. Boost is in the standard locations > (/usr/include/boost/ and /usr/lib/libboost* > >> Btw what platform are you using ? > > Gentoo Michael Gronager, PhD Director, Ceptacle Jens Juels Gade 33 2100 Copenhagen E Mobile: +45 31 45 14 01 E-mail: grona...@ceptacle.com Web: http://www.ceptacle.com/ -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Announcement: libcoin
OK - from your path it looks like linux. What version of Boost do you use. I require 1.47 or 1.48. - I will change that, but it is quite handy for signal_sets - will make an alternative scheme though. And, as for 0.4 vs 0.5 - I have tried to follow the changes, which were mostly (?) related to the integration of the qt client, which would have to be re-done anyway. Then there were some deadlock fixes, that I don't need ;). A fix for a special attack, that I have included. But I will go over everything again. Cheers, M On 01/02/2012, at 16:26, Luke-Jr wrote: > On Wednesday, February 01, 2012 9:18:32 AM Michael Grønager wrote: >> libcoin is now in a state ready for its first release, which I would like >> to share with you! > > Looks interesting. However, it doesn't configure for me: >http://paste.pocoo.org/show/544135/ > > I noticed it's forked from bitcoind 0.4.x. Do you plan to merge up to 0.5.x? > > Luke Michael Gronager, PhD Director, Ceptacle Jens Juels Gade 33 2100 Copenhagen E Mobile: +45 31 45 14 01 E-mail: grona...@ceptacle.com Web: http://www.ceptacle.com/ -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Announcement: libcoin
Hi Luke, Your CMake cannot find boost - use ccmake or cmake-gui to help it with the location. Btw what platform are you using ? /M On 01/02/2012, at 16:26, Luke-Jr wrote: > On Wednesday, February 01, 2012 9:18:32 AM Michael Grønager wrote: >> libcoin is now in a state ready for its first release, which I would like >> to share with you! > > Looks interesting. However, it doesn't configure for me: >http://paste.pocoo.org/show/544135/ > > I noticed it's forked from bitcoind 0.4.x. Do you plan to merge up to 0.5.x? > > Luke Michael Gronager, PhD Director, Ceptacle Jens Juels Gade 33 2100 Copenhagen E Mobile: +45 31 45 14 01 E-mail: grona...@ceptacle.com Web: http://www.ceptacle.com/ -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Announcement: libcoin
Would be fine for me, depends on the community, and it is one of those chunks that make many stall... The reason for building on bitcoin/bitcoin directly is that this created a history of all changes, and this way I had a working version running each day while doing the refactoring - with my wallet at stake! However, I think perhaps the bitcoin project should be split into a library, with a prototype client and the actual clients. This library facilitates this. Cheers, M On 01/02/2012, at 16:09, slush wrote: > Very interesting. Do you have any plans to push your refactored code into > Bitcoin upstream for future releases someday? > > slush > > On Wed, Feb 1, 2012 at 3:18 PM, Michael Grønager > wrote: > Dear Bitcoiners, > > libcoin is now in a state ready for its first release, which I would like to > share with you! > > === libcoin is a crypto currency library based on the bitcoin/bitcoin > "Satoshi" client. === > > Copenhagen, Denmark - 1st February 2012 Ceptacle announces the release of the > first version of the crypto currency library "libcoin" based on the > bitcoin/bitcoin "Satoshi" client. > > libcoin also maintains a version of bitcoind that is a 100% compatible > drop-in replacement of the bitcoin/bitcoind client: You can use it on the > same computer on the same files and you can call it with the same scripts. > And you can easily extend it without touching the basic bitcoin source files. > > The libcoin/bitcoind client downloads the entire block chain 3.5 times faster > than the bitcoin/bitcoind client. This is less than 90 minutes on a modern > laptop! > > In libcoin, the Satoshi client code has been completely refactored, properly > encapsulating classes, removing all globals, moving from threads and mutexes > to a pure asynchronous approach. Functionalities have been divided into > logical units and libraries, minimizing dependencies for e.g. thin clients. > > libcoin is chain agnostic, all chain (bitcoin, testnet, namecoin, litecoin, > ...) specific settings are maintained from a single class (Chain) and hence > experiments with chain settings, mining, security and digital currencies for > research and educational purposes are easily accessible. See the ponzicoin > example for how you define your own chain. > > The build system of libcoin is based on CMake and supports builds of static > and dynamic libraries on Linux, Mac OS X, and Windows. > > The libcoin license is LGPL v. 3. This mean that you can use it in open > source as well as in commercial projects, but improvements should go back > into the libcoin library. > > == > > Read more on libcoin on: http://github.com/ceptacle/libcoin/wiki > > Join libcoin on twitter: http://twitter.com/libcoin > > Download "libcoin Satoshi release": > http://github.com/ceptacle/libcoin/zipball/v0.4.0.1 > > Best regards, > > Michael Gronager, PhD > Director, Ceptacle > Jens Juels Gade 33 > 2100 Copenhagen E > Mobile: +45 31 45 14 01 > E-mail: grona...@ceptacle.com > Web: http://www.ceptacle.com/ > > > -- > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > Michael Gronager, PhD Director, Ceptacle Jens Juels Gade 33 2100 Copenhagen E Mobile: +45 31 45 14 01 E-mail: grona...@ceptacle.com Web: http://www.ceptacle.com/ -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Announcement: libcoin
Well, it should be simple. libcoin separates all the stuff you would like to do from a gui from the actual code, so I think it could be done cleanly. I havn't looked much at qt though... But help would be appreciated ;) /M On 01/02/2012, at 16:02, Wladimir wrote: > Sounds very nice. Congratulations with the release! > > Any plans for porting over bitcoin-qt? > > Wladimir > > Op 1 feb. 2012 15:19 schreef "Michael Grønager" het > volgende: > Dear Bitcoiners, > > libcoin is now in a state ready for its first release, which I would like to > share with you! > > === libcoin is a crypto currency library based on the bitcoin/bitcoin > "Satoshi" client. === > > Copenhagen, Denmark - 1st February 2012 Ceptacle announces the release of the > first version of the crypto currency library "libcoin" based on the > bitcoin/bitcoin "Satoshi" client. > > libcoin also maintains a version of bitcoind that is a 100% compatible > drop-in replacement of the bitcoin/bitcoind client: You can use it on the > same computer on the same files and you can call it with the same scripts. > And you can easily extend it without touching the basic bitcoin source files. > > The libcoin/bitcoind client downloads the entire block chain 3.5 times faster > than the bitcoin/bitcoind client. This is less than 90 minutes on a modern > laptop! > > In libcoin, the Satoshi client code has been completely refactored, properly > encapsulating classes, removing all globals, moving from threads and mutexes > to a pure asynchronous approach. Functionalities have been divided into > logical units and libraries, minimizing dependencies for e.g. thin clients. > > libcoin is chain agnostic, all chain (bitcoin, testnet, namecoin, litecoin, > ...) specific settings are maintained from a single class (Chain) and hence > experiments with chain settings, mining, security and digital currencies for > research and educational purposes are easily accessible. See the ponzicoin > example for how you define your own chain. > > The build system of libcoin is based on CMake and supports builds of static > and dynamic libraries on Linux, Mac OS X, and Windows. > > The libcoin license is LGPL v. 3. This mean that you can use it in open > source as well as in commercial projects, but improvements should go back > into the libcoin library. > > == > > Read more on libcoin on: http://github.com/ceptacle/libcoin/wiki > > Join libcoin on twitter: http://twitter.com/libcoin > > Download "libcoin Satoshi release": > http://github.com/ceptacle/libcoin/zipball/v0.4.0.1 > > Best regards, > > Michael Gronager, PhD > Director, Ceptacle > Jens Juels Gade 33 > 2100 Copenhagen E > Mobile: +45 31 45 14 01 > E-mail: grona...@ceptacle.com > Web: http://www.ceptacle.com/ > > > -- > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development Michael Gronager, PhD Director, Ceptacle Jens Juels Gade 33 2100 Copenhagen E Mobile: +45 31 45 14 01 E-mail: grona...@ceptacle.com Web: http://www.ceptacle.com/ -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Announcement: libcoin
Hi Gregory, I played with the database sync as well to get further speedups, but in the latest version I could only get about 1% extra from this. In the Satoshi client there is a bunch of sleeps and mutexes (put in there with great generosity) for making threads run smoother and to avoid deadlock I guess. The big change in speed came from moving from the threading based setup to the async based setup, so I think these are the culprit. Further, as I also write somewhere in the wiki. I can measure that 50% of the time is consumed in verify, so there is not much left to optimize now. Actually, Berkeley DB does a quite decent job in caching reads so not even a cache should help. Cheers, M On 01/02/2012, at 15:59, Gregory Maxwell wrote: > On Wed, Feb 1, 2012 at 9:18 AM, Michael Grønager > wrote: >> The libcoin/bitcoind client downloads the entire block chain 3.5 times >> faster than the bitcoin/bitcoind client. This is less than 90 minutes on a >> modern laptop! > > Very interesting. Do you know where this speedup came from? It's not > typical for straight refactors that don't change datastructures and > the like to see such big speedups. > > I see you have commented out code that disables fsync, which was my > first guess since I get big speedups from doing similar things. Michael Gronager, PhD Director, Ceptacle Jens Juels Gade 33 2100 Copenhagen E Mobile: +45 31 45 14 01 E-mail: grona...@ceptacle.com Web: http://www.ceptacle.com/ -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Announcement: libcoin
Dear Bitcoiners, libcoin is now in a state ready for its first release, which I would like to share with you! === libcoin is a crypto currency library based on the bitcoin/bitcoin "Satoshi" client. === Copenhagen, Denmark - 1st February 2012 Ceptacle announces the release of the first version of the crypto currency library "libcoin" based on the bitcoin/bitcoin "Satoshi" client. libcoin also maintains a version of bitcoind that is a 100% compatible drop-in replacement of the bitcoin/bitcoind client: You can use it on the same computer on the same files and you can call it with the same scripts. And you can easily extend it without touching the basic bitcoin source files. The libcoin/bitcoind client downloads the entire block chain 3.5 times faster than the bitcoin/bitcoind client. This is less than 90 minutes on a modern laptop! In libcoin, the Satoshi client code has been completely refactored, properly encapsulating classes, removing all globals, moving from threads and mutexes to a pure asynchronous approach. Functionalities have been divided into logical units and libraries, minimizing dependencies for e.g. thin clients. libcoin is chain agnostic, all chain (bitcoin, testnet, namecoin, litecoin, ...) specific settings are maintained from a single class (Chain) and hence experiments with chain settings, mining, security and digital currencies for research and educational purposes are easily accessible. See the ponzicoin example for how you define your own chain. The build system of libcoin is based on CMake and supports builds of static and dynamic libraries on Linux, Mac OS X, and Windows. The libcoin license is LGPL v. 3. This mean that you can use it in open source as well as in commercial projects, but improvements should go back into the libcoin library. == Read more on libcoin on: http://github.com/ceptacle/libcoin/wiki Join libcoin on twitter: http://twitter.com/libcoin Download "libcoin Satoshi release": http://github.com/ceptacle/libcoin/zipball/v0.4.0.1 Best regards, Michael Gronager, PhD Director, Ceptacle Jens Juels Gade 33 2100 Copenhagen E Mobile: +45 31 45 14 01 E-mail: grona...@ceptacle.com Web: http://www.ceptacle.com/ -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Trickle in CNode::SendMessages
Small correction - if the node is the trickle node it gets all invs, not just the special quarter. This means that everything get distributed everywhere every 12-15seconds, but a special quarter of the hash space is treated earlier, so there is a meaning for vInvWait, but there is still a mismatch between comments and code. Cheers, M On 29/12/2011, at 23:05, Michael Grønager wrote: > In CNode::SendMessages there is a trickle algorithm. Judging from the > comments it is supposed to: > > * at each update round a new (random) trickle node is chosen, with 120 nodes > and an average round time of 100ms (the sleep) we will have moved through > roughly all nodes every 12-15 seconds. > * when a node is the trickle node it will get to send all its pending > addresses to its corresponding peer. > * when a node is not trickle node (the rest of the nodes) we send > transaction-invs, however, only 1/4 of them - the rest is pushed to wait for > the next round and would eventually get sent. > > However, the way the 1/4 of the invs are chosen is by: > (inv.getHash() ^ hashSalt) & 3 == 0 > > As hashSalt is a constant (static, generated on start up) and as the hash of > an inv is constant for the inv too, the other 3/4 will never get sent and > hence it does not make sense to carry them around from round to round: > if (fTrickleWait) vInvWait.push_back(inv); > and: > pto->vInventoryToSend = vInvWait; > > The hashSalt will be different for each node in the peer-to-peer network and > hence as long as we have much more than 4 nodes all tx'es will be sent around. > > Ironically, this (wrong?) implementation divides the inv forwarding hash > space into 4, along the same lines as we discussed last week for DHTs... > > I suggest to either keep the algorithm as is, but remove the redundant > vInvWait stuff, or to change the algorithm to e.g. push the tx'es into a > multimap (invHash^hashSalt, invHash) and choose the first 25% in each round. > > The last alternative is that I have misunderstood the code... - if so please > correct me ;) > > Happy New Year! > > Michael > > > -- > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex > infrastructure or vast IT resources to deliver seamless, secure access to > virtual desktops. With this all-in-one solution, easily deploy virtual > desktops for less than the cost of PCs and save 60% on VDI infrastructure > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development Michael Gronager, PhD Owner Ceptacle / NDGF Director, NORDUnet A/S Jens Juels Gade 33 2100 Copenhagen E Mobile: +45 31 62 14 01 E-mail: grona...@ceptacle.com -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Trickle in CNode::SendMessages
In CNode::SendMessages there is a trickle algorithm. Judging from the comments it is supposed to: * at each update round a new (random) trickle node is chosen, with 120 nodes and an average round time of 100ms (the sleep) we will have moved through roughly all nodes every 12-15 seconds. * when a node is the trickle node it will get to send all its pending addresses to its corresponding peer. * when a node is not trickle node (the rest of the nodes) we send transaction-invs, however, only 1/4 of them - the rest is pushed to wait for the next round and would eventually get sent. However, the way the 1/4 of the invs are chosen is by: (inv.getHash() ^ hashSalt) & 3 == 0 As hashSalt is a constant (static, generated on start up) and as the hash of an inv is constant for the inv too, the other 3/4 will never get sent and hence it does not make sense to carry them around from round to round: if (fTrickleWait) vInvWait.push_back(inv); and: pto->vInventoryToSend = vInvWait; The hashSalt will be different for each node in the peer-to-peer network and hence as long as we have much more than 4 nodes all tx'es will be sent around. Ironically, this (wrong?) implementation divides the inv forwarding hash space into 4, along the same lines as we discussed last week for DHTs... I suggest to either keep the algorithm as is, but remove the redundant vInvWait stuff, or to change the algorithm to e.g. push the tx'es into a multimap (invHash^hashSalt, invHash) and choose the first 25% in each round. The last alternative is that I have misunderstood the code... - if so please correct me ;) Happy New Year! Michael -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Protocol extensions
Just adding to Joels comment: The only one with an incentive to do validations are miners (otherwise they could risk having their mined blocks invalidated later by less lazy miners) and the ones who are to send and accept a transaction. In a distributed stored and validated block chain setup, you would hence need to ask some miners if the inputs to a transaction is valid or download all the chain yourselves. The latter is what we do today and will not scale, the former is the logical consequence of a non-enforced random validation approach - so this will give us super nodes, namely miners, and at some point they could choose to also charge for the validations. It might be the direction we are moving towards, but then the p2p network is only for the miners and the rest of us can connect through https and use json-rpc to post transactions etc to them. I do, however, prefer a setup where we keep everything really distributed... /M On 22/12/2011, at 13:14, Joel Joonatan Kaartinen wrote: > On Thu, 2011-12-22 at 11:52 +, Andy Parkins wrote: >> Why should they have to? Joining the network as a node is very low cost to >> the other nodes. You can't force any node not to be lazy, since their >> option >> is to disconnect themselves. As to maliciousness, that is defended against >> because when a node negative announces a transaction, that transaction is >> going to be checked (note that there is still no implicit trust) -- if a >> node >> is incorrectly negative-announcing then it can justifiably be kicked. > > a node that is not doing any checking themselves can not reliably > forward failed verifications without getting the blame for doing faulty > work. Those nodes would then have the incentive not to relay the failed > verifications. This ends up making it important to know which nodes will > be checking transactions or not so you don't isolate yourself from other > nodes that are also checking transactions. > > - Joel > Michael Gronager, PhD Owner Ceptacle / NDGF Director, NORDUnet A/S Jens Juels Gade 33 2100 Copenhagen E Mobile: +45 31 62 14 01 E-mail: grona...@ceptacle.com -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Protocol extensions
It is analog to getting assigned a random part (based on IP) of the hashspace and then only verify transactions within this fraction. But, there is in fact a subtle difference: If anyone can choose to verify at random, you will see lazy implementations where random means none, and as it is random you cannot, from the outside, judge if a node is taking part in the validation work or if it just benefitting from others announcements. In the hash space part, you can monitor peers and see if they did not tell you about a failed validation and then disconnect from them as they are either malicious or lazy. Besides from that, I like a setup where we scream about failed verifications, but keep a low profile on things that actually verifies... /M On 22/12/2011, at 11:12, Andy Parkins wrote: > On 2011 December 21 Wednesday, Christian Decker wrote: > >> Supernodes will be those nodes that verify all transactions and make them >> available to miners. Since miners will become more and more specialized >> these supernodes are likely to be owned by the miners themself. To be a >> miner either you need to verify all the transactions you include (otherwise >> others might be able to find an error in your block and thus drop it) or >> have someone that verifies them for you. In the end I think we'll end up >> with a hierarchical network, with the miners/supernodes tighly >> interconnected at the top and the lightweight clients that simply verify >> transactions (or their inputs to be precise) that are destined for them at >> the bottom. > > A thought occurred to me. We already run a decentralised system, but it's > done by making everyone duplicate all other work. There is no fundamental > reason why all work needs to be duplicated though. What about this: every > node randomly chooses whether to verify any particular transaction. If we > assume the network is large and the random factor is correctly chosen, then > we > can still guarantee that every transaction is verified. Then, we simply add > a > protocol message that is a negative-announce transaction. That is to say, we > give nodes a way of telling other nodes that they think a transaction is > invalid. The other nodes are then free to verify _that_ assertion and > forward > the negative-announce. > > Miners can then listen for negative-announcements and use them to decide were > to dedicate their verification efforts. They then don't need to verify all > (or perhaps even any) transactions themselves and can dedicate their > processing power to mining. > > (I've actually mentioned this idea before, but that time I was using it as a > double-spend prevention method). > > > > Andy > > -- > Dr Andy Parkins > andypark...@gmail.com -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Protocol extensions
Agree, but even before that, we will meet problems of the current 1MB/10min limit. The calculations from the scalability link surely indicates that there are 2 options for scalability either go for trusted supernodes backed by huge hardware resources or something else would be needed. The supernode approach is simple and easy to implement, but it also breaks a lot of the nice features about bitcoin. So if we want bitcoin to stay p2p we need to deploy other strategies. The hash space partitioning is one of them. And the nice thing is that it can be made to scale even for a javascript based validating and fully connected client running on a smartphone in a bitcoin future with billions of clients and transactions, and still it does not exclude you from running a trusted supernode either. Cheers, M On 21/12/2011, at 18:17, Jordan Mack wrote: > I think it would be a lot more than that. According to the Scalability > page (https://en.bitcoin.it/wiki/Scalability) if Bitcoin took over all > credit card transactions, that would be about 1.14GB per block. I > believe that is 58.5PB per year. (6*24*365*1.14/1024) This would also > mean the distribution of 2MB of block data per second, which doesn't > include broadcast overhead. > > On 12/21/2011 12:50 AM, Michael Grønager wrote: >> when bitcoin takes over all credit card transactions (!), and even before >> that, >> we will meet a scalability problem. The blockchain will grow rapidly, >> (1MB/10min or 50GB/yr) > > -- > Write once. Port to many. > Get the SDK and tools to simplify cross-platform app development. Create > new or port existing apps to sell to consumers worldwide. Explore the > Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join > http://p.sf.net/sfu/intel-appdev > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Protocol extensions
I find it likely that we will at some point have supernodes. If we have browser based wallets then the server for these automatically becomes supernodes. Further, if we move along that direction, it becomes much simpler to use both the scheme I proposed or to use a a lot of other schemes for sharing the validation work on a farm constituting the supernode. However, if we want to keep bitcoin in a real p2p setup and enable scalability in terms of ensuring both thin and fat client to connect then we need to go along the path I propose. Actually, after thinking a bit more about the possible new attack vector I don't find it that alarming - if you still require 7 confirmations of any bigger transaction before you, as receiver accepts the transaction as payed you will not risk anything. The question is then if it is sufficiently easy to fake small transaction to e.g. gain access to micropayment based web services. I would again say no - the requirement that you have ok from e.g. 8 different A.B nodes will make it extremely difficult to cheat, and that would even require you to gain some level of control over the network that the service you want to cheat is connected through. This means that you should not divide the hash space more finely than you would at all times be able to find 8 different A.B nodes. As the number of clients grows you can then divide the hash space further. (with 10 nodes today and a division into 512 parts you would have approx 200 nodes to choose from). Cheers, M On 21/12/2011, at 12:42, Eric Lombrozo wrote: > Is it just me or does it seem inevitable that at some point supernodes > will emerge that other nodes trust to validate transactions for them? > Supernodes needn't even store the entire block chain and transaction > pool...it would be sufficient that they keep lists of IP addresses of > other trustworthy nodes and partition them into a hashspace. > > Anonymous peers have no reputation to defend...but a trusted supernode > would, which could provide just enough incentive for the supernode to > do its best to ensure the nodes it vouches for are indeed legit. Of > course, unless the supernode is validating the entire block chain and > transaction pool itself, it could only assess the trustworthiness of > other nodes by performing random sampling. > > Michael, I really like your ideas and the clarity you bring to the > issue. Regarding the potential attack vector you mention, would it be > possible to partition the hashspace to minimize the risk that an > attacker can manage to disproportionately gain control over a part of > the hashspace? > > -- > Write once. Port to many. > Get the SDK and tools to simplify cross-platform app development. Create > new or port existing apps to sell to consumers worldwide. Explore the > Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join > http://p.sf.net/sfu/intel-appdev > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Protocol extensions
> top of a slow system. > > That's really the only thing I wanted to point out - if you do DHTs, focus on > performance, not anonymity. :) > > Cheers, > > Stefan > > On 12/17/2011 2:37 PM, Christian Decker wrote: >> A while back I had proposed a similar idea to the DHT, although my main goal >> was to reduce the need for broadcasts. >> >> My idea was to structure the network in a hypercube and use prefixes to >> address different parts of the network, and use those prefixes also to find >> the location where an item (transaction, block, ...) should be stored. Each >> vertex in the hypercube is a small, highly connected, cluster of nodes. The >> storage would be distributed, messages are routed on behalf of others, which >> makes finding the origin of the query hard to find (think Tor), each node >> would have to store only O(log(p)) items, with p being the prefix length, >> maximum number of hops is equal to the dimension of the hypercube O(log(n)). >> >> Newly created transaction will be sent directly to the location they'll be >> stored and miners retrieve new transactions at regular intervals. It might >> increase delays to the confirmations, but it reduces the number of >> broadcasts and storage requirements on nodes greatly. >> >> Regards, >> Chris >> >> >> On Sat, Dec 17, 2011 at 2:13 PM, Michael Grønager >> wrote: >> Hey Eric, >> >> Two comments. >> >> 1. >> The ability to query for transactions belonging to pubkeys or bitcoin >> addresses is supported today by several implementations: >> * blockexplorer.com >> * bitcoin-js >> * my own libBTC (will more on this soon) >> >> To query for transactions you need to use json-rpc and not the bitcoin >> protocol, however. But still the purpose is the same: to be able to build >> thin clients that can rely on a server for storing the blockchain >> and keeping connected on the p2p network. >> >> The reason for not having these queries part of the standard protocol (I >> think) are as they breaks anonymity, and that you would actually encourage >> people to participate in the p2p. >> >> 2. The second part you mention, to some how move the storage of the >> blockchain into a DHT based storage would be quite nice. The benefit of this >> is that it could be a way to integrate the smaller clients into the network >> without breaking the anonymity. But it should be thought out quite >> carefully. Further, if each client only store a fraction of the blockchain >> we should work out what fraction that need to be in order to ensure a >> similar service level. I would be happy to work with you on this. >> >> Cheers, >> >> Michael >> >> On 17/12/2011, at 08:41, Eric Lombrozo wrote: >> >>> Hey, guys. >>> >>> I haven't posted here before so I'll introduce myself. My name's Eric, >>> I've been developing cryptocurrency-related >>> software for several months now, I've implemented some libraries for >>> dealing with core bitcoin datastructures, made >>> some custom builds of bitcoind and interfaced it with a few apps I've >>> written. >>> >>> In doing so, I've come to appreciate just how little of the potential >>> for the bitcoin protocol is being exploited right now... >>> not only in terms of the script features but in terms of the potential >>> commands and node types that could exist. >>> >>> For instance, the protocol spec at >>> https://en.bitcoin.it/wiki/Protocol_specification only has 16 commands >>> listed and >>> only one service type...despite having a full 12 bytes for a command >>> code and a full eight bytes for a services >>> type. >>> >>> The fact that only one node service type is specified is probably due >>> to the fact that the satoshi client was written >>> to be a standalone monolithic app that took care of all the essential >>> needs for a network of peers. >>> i.e. block chain storage/management, transaction signing/verification, >>> key generation/wallet management, block mining, etc... >>> However, I think there's an urgent need for breaking up all these >>> different tasks into separate components that can run as independent >>> services on different types of devices. >>> >>> One of the big issues I'm dealing with now pertains to block chain >>> storage. As of rig
Re: [Bitcoin-development] Protocol extensions
Hey Eric, Two comments. 1. The ability to query for transactions belonging to pubkeys or bitcoin addresses is supported today by several implementations: * blockexplorer.com * bitcoin-js * my own libBTC (will more on this soon) To query for transactions you need to use json-rpc and not the bitcoin protocol, however. But still the purpose is the same: to be able to build thin clients that can rely on a server for storing the blockchain and keeping connected on the p2p network. The reason for not having these queries part of the standard protocol (I think) are as they breaks anonymity, and that you would actually encourage people to participate in the p2p. 2. The second part you mention, to some how move the storage of the blockchain into a DHT based storage would be quite nice. The benefit of this is that it could be a way to integrate the smaller clients into the network without breaking the anonymity. But it should be thought out quite carefully. Further, if each client only store a fraction of the blockchain we should work out what fraction that need to be in order to ensure a similar service level. I would be happy to work with you on this. Cheers, Michael On 17/12/2011, at 08:41, Eric Lombrozo wrote: > Hey, guys. > > I haven't posted here before so I'll introduce myself. My name's Eric, > I've been developing cryptocurrency-related > software for several months now, I've implemented some libraries for > dealing with core bitcoin datastructures, made > some custom builds of bitcoind and interfaced it with a few apps I've written. > > In doing so, I've come to appreciate just how little of the potential > for the bitcoin protocol is being exploited right now... > not only in terms of the script features but in terms of the potential > commands and node types that could exist. > > For instance, the protocol spec at > https://en.bitcoin.it/wiki/Protocol_specification only has 16 commands > listed and > only one service type...despite having a full 12 bytes for a command > code and a full eight bytes for a services > type. > > The fact that only one node service type is specified is probably due > to the fact that the satoshi client was written > to be a standalone monolithic app that took care of all the essential > needs for a network of peers. > i.e. block chain storage/management, transaction signing/verification, > key generation/wallet management, block mining, etc... > However, I think there's an urgent need for breaking up all these > different tasks into separate components that can run as independent > services on different types of devices. > > One of the big issues I'm dealing with now pertains to block chain > storage. As of right now, it is implemented as sequential > disk files using Berkeley DB in the satoshi client. Then you have > other projects that have been using SQL tables, etc... > But I believe the direction this really needs to move towards is some > sort of distributed hash table...and the database queries > should be performed using the bitcoin protocol itself. Perhaps adding > a few more commands. As things stand right now, > the only way to query for transactions or blocks is by their hash. And > once a transaction gets incorporated into a block and > removed from the transaction pool, one can no longer query it by the > transaction hash without stepping outside the bitcoin protocol. > We need access to the disk file that stores the blocks whether it be > via Berkeley DB or SQL or whatever. > > I propose an extension to the bitcoin protocol to provide methods for > performing more sophisticated queries, such as "Give me > an inventory of transactions involving this particular public key" or > "Give me an inventory all transactions in the last n blocks with > unredeemed outputs." This could be done by adding a few more commands. > > Furthermore, I propose a new network services type for nodes that > serve as block chain/transaction pool storage. > > Of couse, any peer that wishes to verify the integrity of the block > chain would still have to download at the very least > all the block headers...and to be completely sure, also all the blocks > themselves...and verify everything. But it would be > very nice to be able to run thin services that can rely on other > network peers to do this work. It is still possible to attain > a high level of confidence in the integrity by querying multiple peers > for similar objects and comparing. It is also possible > to run your own dedicated block chain storage servers which you trust. > > There are other ideas I have for other types of services, too. > > Anyhow, I'm just throwing this out there...if anyone's interested I'd > love to develop these ideas further and help put together some > specs. > > -Eric Lombrozo > > -- > Learn Windows Azure Live! Tuesday, Dec 13, 2011 > Microsoft is holding a special Learn Windows Azure training eve
[Bitcoin-development] CDataStream
OK, I admit that this is *really* of little importance... But could someone with commit rights please update the CDataStream test table in the code. The arguments for the custom stream are just way off (stringstream wins by factor 10-20!). On OS X (g++) I get: Further, if you get(got) bad stringstream numbers on e.g. windows (dikumware had some issues several years ago) you can improve just by changing the default allocation chunk size. So... speed is not a reason for reimplementing stringstream. (And perhaps this can motivate someone to revert bitcoin to stringstream ;-) Cheers, Michael PS: Could be fun to see the output on other OS'es ! serialize.h (with TESTCDATASTREAM defined, i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)): CDataStream: n=1000 0 seconds n=2000 0 seconds n=4000 0 seconds n=8000 0 seconds n=16000 0 seconds n=32000 0 seconds n=64000 1 seconds n=128000 1 seconds n=256000 2 seconds n=512000 4 seconds n=10240008 seconds n=204800017 seconds n=409600040 seconds stringstream: n=1000 0 seconds n=2000 0 seconds n=4000 0 seconds n=8000 0 seconds n=16000 0 seconds n=32000 0 seconds n=64000 0 seconds n=128000 0 seconds n=256000 0 seconds n=512000 0 seconds n=10240000 seconds n=20480001 seconds n=40960002 seconds -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence...
Hi Alan,
I have now read BIP0010 - one first idea is: add a link to it on the wiki (or
remove all bip links from the wiki... - we don't want two places for BIPs...)
I am not sure where you prefer the discussion on the content of the BIP - but
now you get it here, but feel free to redirect...
Likes:
* inclusion of prevout txout scripts - could prove handy
* that it is a proposal to do this similarly on all clients
Dislikes:
* the format - I guess I would prefer a normal JSON format - where the scripts
gets populated step by step. As for the scriptPubKey (now an awful name...) it
would be easy to just add it to the JSON, or have the prevouts simply be the
actual txouts instead of {hash,n}.
Comments:
* it is good to have this proposal, but I think that once we see ways to
communicate it they could very well radically steer how a format should look.
Take e.g. the discussion we had with Gavin yesterday, if we had chosen to move
in that direction BIP0010 would had been useless. So perhaps a bit premature?
Cheers,
Michael
On 10/11/2011, at 04:00, Alan Reiner wrote:
> The purpose of creating BIP 0010 now, is to encourage a standard that
> developers want to adopt, from the outset. Every developer who is planning
> to touch multi-signature transactions, is going to have to solve the problem
> of multi-sig tx exchanges, eventually. By offering an excellent solution
> before they've started asking the question, there's a good chance people will
> use it. Hear me out...
>
> Protocols get fragmented when there's multiple competing ways to do
> something, each having some advantages the others don't have. This leads to
> developers with differing priorities picking different ones, or creating
> their own. However, I believe that the problem BIP 0010 seeks to solve is a
> fairly straightforward problem. There's not a lot of variety in the
> solutions that could compete against it. People just need a way to pass this
> data around, and they want it to be as convenient to use, and as easy to
> implement as possible. In that sense, I think BIP 0010 (or some future
> variant) is fairly optimal as a building block for higher-level protocols.
>
> If anyone has ideas for why someone would want to create a competing idea to
> BIP 0010 (besides not being aware of it when they start), I'd like to discuss
> it. I'm fairly confident that any such ideas could just be added to BIP 0010
> and thus reset the question of why anyone would need a competing idea.
>
>
>
> On 11/09/2011 03:03 PM, Michael Grønager wrote:
>> My main concern when it comes to introducing other protocols is that they
>> might never be standard (I think a great number of clients will emerge - and
>> this would be a thing to compete on). If it is part of the p2p network it
>> will be a seamless standard and easy for everyone to use, even across
>> different clients. But I share your concern on the
>>
>> /M
>>
>
> --
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Michael Gronager, PhD
Owner Ceptacle / NDGF Director, NORDUnet A/S
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 62 14 01
E-mail: grona...@ceptacle.com
Michael Gronager, PhD
Owner Ceptacle / NDGF Director, NORDUnet A/S
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 62 14 01
E-mail: grona...@ceptacle.com
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence...
Crossing posts ;) I like your idea! - It adds a pricetag to distributing a signature - and - as you mention it will be part of the standard. It is only up to the clients if they want to support it or not, but it does give you 0-conf world wide instantaneous anonymously distribution of half-baked transactions... However, the parties will anyway need to know at least about each others public keys up front and hence the 0-conf might not be that important... Left is, as you said, some anonymity (not much extra though)... /M On 09/11/2011, at 21:02, Gavin Andresen wrote: >> I don't think partially-signed transactions belong on the main Bitcoin >> P2P network, mostly because I don't see any way of preventing somebody >> from endlessly spamming bogus, will-never-be-completed partial >> transactions just to be annoying. > > ... of course I write that and then start thinking about ways you > COULD use the P2P network to distribute signatures, maybe by > broadcasting (and paying fees for) complete transactions that contain > extra signatures for the transaction that you want to sign. > > Here's a half-baked idea that might be brilliant or stupid: > > + Start with an escrow transaction, with 3 public keys. I own one of the > keys. > + I broadcast a 'fee-only' transaction that pays 0 bitcoins to the key > I own. But I add extra data to the scriptSig; something like: > > scriptSig: > scriptPubKey: ...standard DUP HASH160 ...etc > nValue: 0 > > The other parties to the escrow transaction could monitor the > block-chain for transactions to my , and get the signature > and proposed "spend the funds in escrow" transaction from the > scriptSig. > > ... > > "But won't that gunk up the block chain with more data?" > > Yup. But the parties to the transaction will have to pay for the > extra data they're including. > > And everything in the scriptSigs can, theoretically, be forgotten (or > never sent) to most nodes on the network once the transaction is spent > and is buried deep enough in the block chain. (a nValue=0 transaction > can be considered 'immediately spent'). > > "Can you really put arbitrary stuff in the scriptSig?" > > Yup. The IsStandard() check today allows up to 200 bytes, which > wouldn't be enough for an extra signature and transaction>. > > The standard is about 150 bytes; part of the > multi-signature proposal will be increasing that to 500 bytes to > accomodate 3-signatures transactions. A simple 1-input-1-output > would be around 50 bytes or so. > > "Wouldn't it be cheaper/better to NOT use the block chain to > distribute signatures?" > > Yup. The only advantage I see is it might be more anonymous to use the > blockchain instead of directly connecting to, and finding out the IP > address of, the parties involved in the transaction. > > > -- > -- > Gavin Andresen Michael Gronager, PhD Owner Ceptacle / NDGF Director, NORDUnet A/S Jens Juels Gade 33 2100 Copenhagen E Mobile: +45 31 62 14 01 E-mail: grona...@ceptacle.com -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence...
Hi Gavin / Alan, Agree that we would also need to consider these "half" transaction valid. At least for the time being up to the lock_time, and one could have an extra constrain - that the lock_time should be within e.g. 30minutes that would avoid the will-never-be-completed cases. My main concern when it comes to introducing other protocols is that they might never be standard (I think a great number of clients will emerge - and this would be a thing to compete on). If it is part of the p2p network it will be a seamless standard and easy for everyone to use, even across different clients. But I share your concern on the I can, however, also understand your worries, and some other constraints should be introduced to ensure that not even short time spamming is possible... /M On 09/11/2011, at 20:13, Gavin Andresen wrote: >> 1. from client1 I issue a transaction containing one of the signatures, with >> a locktime e.g. 10 minutes from now and a sequence of 0. This transaction is >> now posted to the p2p network. > > As Alan said, that won't work-- it will not be relayed across the > network because it isn't a valid transaction until it has enough > signatures. > >> Alternatively, the transactions would need to be sent between clients using >> another protocol... > > Formats and protocols for gathering signatures are in the TODO > category-- Alan's BIP 10 is the next piece of the puzzle, maybe a > standardized http/https RESTful API, or HTTP/JSON, or protocol buffers > and raw sockets, or... something... solution (or solutions) built on > top of that makes sense. > > I don't think partially-signed transactions belong on the main Bitcoin > P2P network, mostly because I don't see any way of preventing somebody > from endlessly spamming bogus, will-never-be-completed partial > transactions just to be annoying. > > -- > -- > Gavin Andresen -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] multisig, op_eval and lock_time/sequence...
Hi All, Along with the multisig/op_eval BIPs (11/12) I am considering how the actual client functionality could be. Some of you might already have the solution for this - if not I would like to propose the following... Lets consider the 2 of 3 multisig - and lets say I now have some coins hence only redeemable using 2 key signatures. So when I want to spend them I would do: 1. from client1 I issue a transaction containing one of the signatures, with a locktime e.g. 10 minutes from now and a sequence of 0. This transaction is now posted to the p2p network. 2. client2 discovers the transaction and that it will affect its wallet. It hence modifies the transaction to includes also the second signature, changes the sequence to 0x=final and the lock_time to 0 and retransmits the transaction. 3. The transaction is now valid and final and will be approved by the miners. However, for this setup to be possible, we need to reenable the replacement of transaction in the client Anyone working on this now ? Alternatively, the transactions would need to be sent between clients using another protocol... Cheers, Michael -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Detecting OP_EVAL scriptPubKeys that are to you
> > How would I know that unless you told me? At least you would have a hunch that something like that had happened as one of your addresses had been part of a transaction (at least in my setup it would pop up immediately...). > > I think the right long-term solution is moving away from bitcoin > addresses as 'pay-to entity' and create an infrastructure where we're > paying people or organizations. I am not sure what you mean by this - just recall that the semi anonymously feature of bitcoin is one of its key features. > But in the short term, I think there > are lots of benefits to creating a new type of bitcoin address built > on top of OP_EVAL that will be very easy for all of our existing > infrastructure to support. Still, how do you solve the end less expansions of bitcoin addresses that each, depending of a leading 1, 2, 3... means a quite specific script inside the OP_EVAL ??? Its not esthetic... Cheers, M > > -- > -- > Gavin Andresen -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World™ now supports Android™ Apps for the BlackBerry® PlayBook™. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Detecting OP_EVAL scriptPubKeys that are to you
> Could you suggest how else we could gain the advantages of op_eval > without it? How can I secure my wallet under whatever scheme I like— > create a trust that requires multiparty signoff— and securely have > senders pay into it without expecting them all to handle some rare and > complicated procedure for sending to me? Yes - by the burdensome address ;) - which I am not sure I consider that much of a trouble, for practical uses... Anyway, it could just be added to the URI scheme and then it would still only be a click away. > but it > seems to me that there is a serious misunderstanding that there is a > bijection between hash160s and public keys, and one between ECC > private keys and spendable transactions, and that this bijection is > desirable or even essential to bitcoin. So far we had by the standard transactions a nice bijection, I do however, share your concern for other and more rich scripting... And here we need to make some choices! Do we want to keep this notion of transactions between addresses or do we want to start unfold the richness of the scripting - I am not sure we actually gain that much from OP_EVAL and the extra scripting. And what bothers me is that you then cannot define a set of data (be that key, scripts or whatever) from which you can obtain all possible txes send to you. If I e.g. looses this argument and want to donate a beer to each of you and Gavin, that I want you to drink together. I would make a "both of two" btc-addresses script transaction using OP_EVAL. And post it. You would then not be able to know that you actually got a beer unless I told you so in a mail. This means that we move from a setup where transactions needs not only to be asked for but also they need to be announced by the sender. I don't like this... Further, if you make a uint160 from a OP_EVAL script and post this as a bitcoin address - the user should then know that this was a special address - otherwise he would be sending money nowhere. I agree that this could be encoded into the bitcoin address using e.g. a 2... instead of a 3..., but as you mention yourself this is only the start of the OP_EVAL uses and hence you would need a whole series of strange numbering to define what script a specific address was referring to. At least it challenges my esthetics... Cheers, M -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Detecting OP_EVAL scriptPubKeys that are to you
OK, let me try to explain what I see is the problem: So far we the bitcoin addresses are (for all practical purposes) a one-to-one mapping between a pubkey and uint160. This mean that your wallet is defined solely by your privatekeys (from which you can extract pubkeys and then uint160 btc-addresses). This also enables you to make a uint160 to tx mapping on a server (like on blockexplorer) and use a thin client to query for transactions just from a list of uint160 (whether it holds the private keys behind them or not). In the case of a multisig transaction, lets say the 2of3 example, you could e.g. have all 3 corresponding uint160s but only one privkey, but still query the server and know the value of an asset of uint160s. This, I find a nice and clean setup, where cryptographic keys can be mapped to assets. If we now consider the OP_EVAL proposal. Here, a new use of the uint160, namely as a mapping of ripemd160(something extra and hash256(pubkey)) is introduced. This means that this clean mapping is broken. Your will have an extra "public key" being the "something extra", and there is no easy way to do the mapping from a list of private keys to public keys to uint160s that will result in the new condensed uint160, except if you also have the knowledge of the script that was used. I agree that it will work and I (and bitcoin-js and blockexplorer) can of change the concept of a wallet to also include scripts, but it breaks an intrinsic logic of uint160s and transactions that has so far been quite nice and clean. So I also support checkmultisig to be the standard transaction type, but I do not appreciate the support of OP_EVAL. Cheers, Michael On 26/10/2011, at 17:00, Gavin Andresen wrote: > On Wed, Oct 26, 2011 at 4:58 AM, Michael Grønager > wrote: >> I think it is a very important feature to be able to extract transaction >> to/from you only from your private keys. > > Why? If somebody is sending me bitcoins, then they'll have to get > either an address or one or more public keys from me. OP_EVAL just > lets me give them a short address that represents an arbitrary number > of keys combined in an arbitrary way. > > I agree with Gregory: it shouldn't matter if that address is > HASH(public key) or HASH(op_eval_script), the issues are the same (if > you lose or cannot re-create the key/script then you're in trouble). > > Maybe I'm missing something; are you worried that blockexplorer won't > know that coins sent to HASH(op_eval_script) are actually a > complicated transaction until the coins are spent again? I'd consider > that a feature, not a bug, because only the people involved in the > transaction need to know the details until after the transaction is > complete. > > Feel free to contact me about your 'tiered implementation for thin > clients' -- I don't think OP_EVAL will make that significantly harder. > > I also agree with Alan: using OP_EVAL is not mandatory, I'm proposing > that CHECKMULTISIG becomes a standard transaction type. > > -- > -- > Gavin Andresen Michael Gronager, PhD Owner Ceptacle / NDGF Director, NORDUnet A/S Jens Juels Gade 33 2100 Copenhagen E Mobile: +45 31 62 14 01 E-mail: grona...@ceptacle.com -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Detecting OP_EVAL scriptPubKeys that are to you
I think it is a very important feature to be able to extract transaction
to/from you only from your private keys. In the standard transactions this is
easily accomplished - in the case you only want to find the addr to tx mapping:
vector > > vSolution;
if (!Solver(scriptPubKey, vSolution))
return 0;
BOOST_FOREACH(PAIRTYPE(opcodetype, vector)& item, vSolution)
{
vector vchPubKey;
if (item.first == OP_PUBKEY)
// encode the pubkey into a hash160
return Hash160(item.second);
else if (item.first == OP_PUBKEYHASH)
return uint160(item.second);
}
This possibility is used today in:
* blockexplorer
* bitcoin-js
* my own tiered implementation for thin clients
I agree that you can of course always construct payment schemes to hide
payments (hashes from classic novels, sending the private key off line etc),
but I consider those either exotic or on purpose hidden, and hence they are not
really a problem, nor an argument that this feature does not really exist today.
So, if we introduce a standard (multikey) payment that hides the address (or
makes it overly complicated to extract it) it will be a major problem for the
projects that I listed above.
I will post a more detailed technical comment reflecting directly on the BIPs,
but the wiki is currently down and I need to re-read the BIPs first.
Cheers,
Michael
On 25/10/2011, at 18:47, Alan Reiner wrote:
> On Tue, Oct 25, 2011 at 10:49 AM, Gregory Maxwell wrote:
> On Tue, Oct 25, 2011 at 9:21 AM, Gavin Andresen
> wrote:
>> You give the hash to whoever is paying you, and store the hash -->
>> script mapping when you do that (assuming you're not using a
>> deterministic wallet; if you are, you probably just increment a
>> counter in the wallet).
>
> If anyone finds that solution unsatisfying, consider— It's already the
> case that I could take one of your disclosed public keys and create an
> infinite series of secondary keys out of it for which only you could
> decode, and the only way for you to find them in the blockchain would
> be to have performed the same procedure and made a note of the
> addresses you're watching for.
>
>
> (1) As I understand it, OP_EVAL is being proposed as an *optional* tool for
> multi-signature transactions. It sounds like to me, that you can still use
> the regular OP_CHECKMULTISIG if you are concerned about these things. If
> you're dealing with too many parties with questionable reliability that they
> will notify you of transacitons that include you, I don't see anything wrong
> with declaring that you'd only prefer dealing with OP_CMS transactions and
> not OP_EVAL (besides some grumbling from them that their way is "better").
> Either way, they're screwing themselves, too, if they want to include you on
> transactions and don't notify you as such (kind of defeats the purpose of
> multi-sig txs).
>
> (2) I think it's unnecessary to discuss cases where you somehow lose your
> mappings but not your private keys. In order for OP_EVAL scripts to work,
> the subscripts/mappings are *just as important* as your regular private keys.
> They should be kept in your wallet forever just like your private keys--and
> thus you lose none of them or all of them. The only real difference is that
> they aren't sensitive like your private keys, so they don't have to be
> encrypted.
>
> (3) There should most definitely be a button on the main client that allows
> you to "Add OP_EVAL script" or something along those lines (maybe something
> with a less obscure name). We need to make it as easy as possible for
> someone to add such a script/mapping to their wallet. Although, this invites
> a breach of one of my core rules of user interfaces: if the functionality is
> dependent on the user performing some regular maintenance task, you better be
> prepared for all users to fail at doing it. Even diligent users are going to
> forget/mess-up sometimes. If failure at performing this task results in
> breaking the client or losing money, we should avoid promoting that usage
> paradigm.
>
> --
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@
Re: [Bitcoin-development] vtxPrev
Oups - I was reading the code wrongly - going through AddSupportingTransactions carefully again... The vtxPrev contains a list of the supporting confirmations up to 3 confirmations back. So it is only of relevance (and only gets filled) if you accept coins that are less than 3 confirmations old. In this case you would like to resend the depending transactions to the network in case of chain splits. This makes much more sense, but also, it is only of relevance when you accept newly earned coins. And it will only be of relevance for half an hour or so. Cheers, Michael On 05/10/2011, at 14:50, Gregory Maxwell wrote: > On Wed, Oct 5, 2011 at 8:31 AM, Michael Grønager > wrote: >> The vtxPrev stores 3 transactions back, but as transactions need 7 block to >> maturity and respendability isn't it overkill - I mean it is highly unlikely >> that a transaction gets invalid after 7 confirmations and > > They don't need 7 blocks to maturity and respendability. The software > will attempt to use older inputs when available but if not it will use > what it has. It's also prone to respending its own outputs quickly > because it reasonably trusts that it won't doublespend its own > transactions. > > And, yes, if there is a deep split then its possible that inputs might > have been spent differently in the new split. But it's not especially > likely. Retransmitting one of your own txn's parents if its dropped > but not yet impossible sounds prudent to me. Michael Gronager, PhD Owner Ceptacle / NDGF Director, NORDUnet A/S Jens Juels Gade 33 2100 Copenhagen E Mobile: +45 31 62 14 01 E-mail: grona...@ceptacle.com -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] vtxPrev
Hi ! I am looking into enabling a split between thin clients holding the wallet and server(s) holding the blocks and txdb. To that end I am considering to simplify the WalletTx a bit and I came across the vtxPrev in the code. As I see it vtxPrev is only used for keeping a list of supporting transactions to enable resubmit of these in case the transaction it self and all its supporting transactions are lost due to some blocks becoming invalid as they are part of a dead-end part of the chain. However... The vtxPrev stores 3 transactions back, but as transactions need 7 block to maturity and respendability isn't it overkill - I mean it is highly unlikely that a transaction gets invalid after 7 confirmations and the vtxPrev are guarding against resubmission of transaction more than 21 confirmations back. Further, we cannot guarantee that the transaction owner is online at the time and the money could have been re-spent for others anyway. So bottom line: Do we need the vtxPrev at all ? Or did I miss out something ? Cheers, Michael -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Mac libboost_thread or thread-mt?
Hi Brian, Had a similar issue the other day with my cmake btc buildsystem - I just changed the name to -mt, I think that is th way to go. Cheers, Michael On 05/10/2011, at 01:40, Brian McQueen wrote: > I installed boost via the mac ports. Its got lobboost_thread-mt, but > it doesn't have libboost_thread.a. Should I modify the makefile or get > a different version of boost? > > -- > Make a Small Loan, Make a Big Difference - Check out Kiva.org to Learn How! > > -- > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.4rc1 known bugs
Sorry, by bad - first clean checkout for quite a while (must have changed it earlier myself...). /M On 05/09/2011, at 14:42, Luke-Jr wrote: > On Monday, September 05, 2011 3:25:47 AM Michael Grønager wrote: >> Findings - compile (I do not use the UPNP feature): >> in the makefile.unix I have to change the: >> USE_UPNP:=0 >> to >> USE_UPNP:= >> i.e. it is defined if it is "0" ! > > Yes, the default is "UPnP supported, disabled by default" (USE_UPNP=0), not > "UPnP not supported" (USE_UPNP=). This is documented in build-unix.txt ... > > -- > Special Offer -- Download ArcSight Logger for FREE! > Finally, a world-class log management solution at an even better > price-free! And you'll get a free "Love Thy Logs" t-shirt when you > download Logger. Secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsisghtdev2dev > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development Michael Gronager, PhD Owner Ceptacle / NDGF Director, NORDUnet A/S Jens Juels Gade 33 2100 Copenhagen E Mobile: +45 31 62 14 01 E-mail: grona...@ceptacle.com -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.4rc1 known bugs
Hi Gavin, Did a quick compile and run (bitcoind, Ubuntu 10.04.3 LTS) Findings - compile (I do not use the UPNP feature): in the makefile.unix I have to change the: USE_UPNP:=0 to USE_UPNP:= i.e. it is defined if it is "0" ! running: no apparent issues (I have never managed to trigger the deadlocks.?.) Nice job, but a quick cleanup of interfaces and classes (one file pr class, all interfaces defined in headers) would really be nice... Would be happy to do it myself, as it would greatly enhance the flexibility of the code and be a first step towards a more library/interface like split. Cheers, Michael On 04/09/2011, at 02:13, Gavin Andresen wrote: > Quick status update on 0.4; I probably won't have time to tackle these > properly before Tuesday: > > + sipa found what looks like a deadlock between the addr-handling and > IRC-join-handling code. > + UukGoblin reports a deadlock problem on a bitcoind handling getwork > requests. > > If you want to get more familiar with the bitcoin code and you have a > lot of patience, tracking down deadlocks a great way to do it. > > + ArtForz found a performance bug with transactions that have > thousands of inputs and outputs on the solidcoin test network. > (not as big an issue for bitcoin due to fees being based on > transaction size, but still worrying) > > -- > -- > Gavin Andresen > > -- > Special Offer -- Download ArcSight Logger for FREE! > Finally, a world-class log management solution at an even better > price-free! And you'll get a free "Love Thy Logs" t-shirt when you > download Logger. Secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsisghtdev2dev > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development Michael Gronager, PhD Owner Ceptacle / NDGF Director, NORDUnet A/S Jens Juels Gade 33 2100 Copenhagen E Mobile: +45 31 62 14 01 E-mail: grona...@ceptacle.com -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New standard transaction types: time to schedule a blockchain split?
Hi Gavin (the list escaped the cc...), I participated also in the hacakathon Sunday @ OnlyOneTV and I felt that this had a strong chance to diverge. So - yes - I agree - no "constitution" changes now. Further, I have thought later on on the analogy of a clerk and a safe. WHen you enter the bank you hand over your money to the clerk (one key) - then after the clerks wallet has been filled over the day _he_ transfers the money to the safe (3 keys). My point is do we really need the customer to bypass the clerk and have 3 key addresses, or could we just leave it to the/a client to implement the multisign transaction after the money has been received - as a transfer to a safe? This would greatly simplify the problem and cover the vast majority of use cases. Not covered in this is huge single transfers where the intruder of a single key system finds it profitable to reveal their intrusion by grabbing the entire wallet. Put in another way - do we *really* need to couple the securing of the wallet to creating a new address type ? Cheers, M On 24/08/2011, at 19:57, Gavin Andresen wrote: > This discussion is convincing me that scheduling a blockchain split is > definitely the wrong idea at this time. We can revisit in N months, > when we've got a roadmap and nice unit tests and a bunch of > well-tested patches for fixing all of the things that aught to be > fixed when we DO decide a blockchain split is necessary. > > There seems to be rough consensus that new, imperfect standard > transactions are a good-enough short term solution. > > -- > -- > Gavin Andresen > > -- > EMC VNX: the world's simplest storage, starting under $10K > The only unified storage solution that offers unified management > Up to 160% more powerful than alternatives and 25% more efficient. > Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development Michael Gronager, PhD Owner Ceptacle / NDGF Director, NORDUnet A/S Jens Juels Gade 33 2100 Copenhagen E Mobile: +45 31 62 14 01 E-mail: grona...@ceptacle.com -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
