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] 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::vectorunsigned char(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 m...@justmoon.de 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 respond. Discussions
will include endpoint security,
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 way for bitcoin functioning for example as a Tor or I2P hidden service, by using onioncat-like
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
OK - didn't took the weekend:
support for port is on github now :)
Only took two lines:
(port, valueunsigned short(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_caststring(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 grona...@ceptacle.com
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 - ジェームズ thiagocmarti...@gmail.com
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 grona...@ceptacle.com
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
Re: [Bitcoin-development] Announcement: libcoin
' ../../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_iteratorunsigned char*, std::vectorunsigned char, std::allocatorunsigned char (__gnu_cxx::__normal_iteratorunsigned char*, std::vectorunsigned char, std::allocatorunsigned char , __gnu_cxx::__normal_iteratorunsigned char*, std::vectorunsigned char, std::allocatorunsigned char )': Script.cpp:(.text._Z4HashIN9__gnu_cxx17__normal_iteratorIPhSt6vectorIhSaIhE7uint256T_S8_[uint256 Hash__gnu_cxx::__normal_iteratorunsigned char*, std::vectorunsigned char, std::allocatorunsigned char (__gnu_cxx::__normal_iteratorunsigned char*, std::vectorunsigned char, std::allocatorunsigned char , __gnu_cxx::__normal_iteratorunsigned char*, std::vectorunsigned char, std::allocatorunsigned char )]+0x6d): undefined reference to `SHA256' Script.cpp:(.text._Z4HashIN9__gnu_cxx17__normal_iteratorIPhSt6vectorIhSaIhE7uint256T_S8_[uint256 Hash__gnu_cxx::__normal_iteratorunsigned char*, std::vectorunsigned char, std::allocatorunsigned char (__gnu_cxx::__normal_iteratorunsigned char*, std::vectorunsigned char, std::allocatorunsigned char , __gnu_cxx::__normal_iteratorunsigned char*, std::vectorunsigned char, std::allocatorunsigned char )]+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 grona...@ceptacle.com 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/ -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud
Re: [Bitcoin-development] Announcement: libcoin
._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_iteratorunsigned char*, std::vectorunsigned char, std::allocatorunsigned char (__gnu_cxx::__normal_iteratorunsigned char*, std::vectorunsigned char, std::allocatorunsigned char , __gnu_cxx::__normal_iteratorunsigned char*, std::vectorunsigned char, std::allocatorunsigned char )': Script.cpp:(.text._Z4HashIN9__gnu_cxx17__normal_iteratorIPhSt6vectorIhSaIhE7uint256T_S8_[uint256 Hash__gnu_cxx::__normal_iteratorunsigned char*, std::vectorunsigned char, std::allocatorunsigned char (__gnu_cxx::__normal_iteratorunsigned char*, std::vectorunsigned char, std::allocatorunsigned char , __gnu_cxx::__normal_iteratorunsigned char*, std::vectorunsigned char, std::allocatorunsigned char )]+0x6d): undefined reference to `SHA256' Script.cpp:(.text._Z4HashIN9__gnu_cxx17__normal_iteratorIPhSt6vectorIhSaIhE7uint256T_S8_[uint256 Hash__gnu_cxx::__normal_iteratorunsigned char*, std::vectorunsigned char, std::allocatorunsigned char (__gnu_cxx::__normal_iteratorunsigned char*, std::vectorunsigned char, std::allocatorunsigned char , __gnu_cxx::__normal_iteratorunsigned char*, std::vectorunsigned char, std::allocatorunsigned char )]+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 grona...@ceptacle.com 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
Re: [Bitcoin-development] Announcement: libcoin
._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_iteratorunsigned char*, std::vectorunsigned char, std::allocatorunsigned char (__gnu_cxx::__normal_iteratorunsigned char*, std::vectorunsigned char, std::allocatorunsigned char , __gnu_cxx::__normal_iteratorunsigned char*, std::vectorunsigned char, std::allocatorunsigned char )': Script.cpp:(.text._Z4HashIN9__gnu_cxx17__normal_iteratorIPhSt6vectorIhSaIhE7uint256T_S8_[uint256 Hash__gnu_cxx::__normal_iteratorunsigned char*, std::vectorunsigned char, std::allocatorunsigned char (__gnu_cxx::__normal_iteratorunsigned char*, std::vectorunsigned char, std::allocatorunsigned char , __gnu_cxx::__normal_iteratorunsigned char*, std::vectorunsigned char, std::allocatorunsigned char )]+0x6d): undefined reference to `SHA256' Script.cpp:(.text._Z4HashIN9__gnu_cxx17__normal_iteratorIPhSt6vectorIhSaIhE7uint256T_S8_[uint256 Hash__gnu_cxx::__normal_iteratorunsigned char*, std::vectorunsigned char, std::allocatorunsigned char (__gnu_cxx::__normal_iteratorunsigned char*, std::vectorunsigned char, std::allocatorunsigned char , __gnu_cxx::__normal_iteratorunsigned char*, std::vectorunsigned char, std::allocatorunsigned char )]+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 grona...@ceptacle.com 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
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
[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
[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 Address 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
[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] 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 grona...@ceptacle.com 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
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 grona...@ceptacle.com 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
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 grona...@ceptacle.com 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
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
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
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
[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] 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
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
[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
[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] 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: escrow_signature serialized_escrow_transaction sig pubkey scriptPubKey: ...standard DUP HASH160 pubkeyhash ...etc nValue: 0 The other parties to the escrow transaction could monitor the block-chain for transactions to my pubkeyhash, 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 serialized transaction. The standard sig pubkey 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 serialized transaction 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] 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 grona...@ceptacle.com 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:
vectorpairopcodetype, vectorunsigned char vSolution;
if (!Solver(scriptPubKey, vSolution))
return 0;
BOOST_FOREACH(PAIRTYPE(opcodetype, vectorunsigned char) item, vSolution)
{
vectorunsigned char 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 gmaxw...@gmail.com wrote:
On Tue, Oct 25, 2011 at 9:21 AM, Gavin Andresen gavinandre...@gmail.com
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
[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] 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
