Latest posts of: Yoghurt114

Show Posts
Pages: [1]

Bitcoin / Project Development / Re: Beta release of an open source block explorer you can run on top of a node

on: July 16, 2015, 09:11:06 PM

Quote from: ikydesu on July 16, 2015, 04:46:29 PM i've tried to enter an addy on text box, then press enter, but nothing happens. Correct, addresses are not supported because the blockchain, in actuality, isn't aware of their existence. This explorer is meant to be run on top of a full node, full nodes don't keep an index for all addresses that exist, only that which has been indexed for the wallet. That said, it's probably a good idea to have some kind of feedback for BASE58CHECK input, and show some heuristics. Thanks. ==== The basic idea and design goal of this explorer is to display simply, yet deeply, what the contents of the blockchain are, what they are made of, what they look like and what they mean. Addresses are 'just' an application on top of the blockchain which allows us to easily assign ownership, but at its core they are not directly related. Thanks.

Bitcoin / Project Development / Beta release of an open source block explorer you can run on top of a node

on: July 16, 2015, 10:30:31 AM

Hi folks, I've hobbyistically been working on a block explorer you can run on top of a node for some time now. Yesterday, I decided it was ready for a public beta release. https://github.com/JornC/bitcoin-transaction-explorer/releases/tag/beta === Bitcoin node block explorer Simple and pure block explorer you can run on top of a full node. This block explorer patches into your Bitcoin Core node's JSON-RPC interface to retrieve transaction and block information. It runs as a simple web application you can run on any J2EE Web Container (Jetty, Tomcat, etc.), point it toward your node and you're good to go. (Note: it also supports running on top of Blockr's API and maybe some others later on) This block explorer remains pure to the blockchain, this means it is not dependent on any source of data other than the blockchain. Bitcoin amount values will not be displayed in fiat, transaction or block receive times do not exist. In this initial release, even addressess are not recognized, nor can a balance be derived for them (without heaps of effort). Addresses may be integral to bitcoin, but the blockchain itself does not have any knowledge of them, they are not included for this reason. ==== Hosting This block explorer is currently being hosted on 3 full nodes: http://srv1.yogh.io - United Kingdom http://srv2.yogh.io - The Netherlands http://srv3.yogh.io - Los Angeles Anyone who would like to host another instance is welcome and encouraged to do so. Instructions to do this are on the GitHub's README. ==== Example usage The lookup textbox understands a lot of bitcoin related stuff you stick in it. Raw transactions, raw blocks, tx id's, block height, and some keywords. Block height: http://yogh.io/#block:height:0 http://yogh.io/#block:height:200000 Block last: http://yogh.io/#block:last Block raw: http://yogh.io/#block:raw:0100000000000000000000000000000000000000000000000000000000000000000000003BA3EDF D7A7B12B27AC72C3E67768F617FC81BC3888A51323A9FB8AA4B1E5E4A29AB5F49FFFF001D1DAC2B 7C Tx id: http://yogh.io/#tx:id:f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16 Tx raw: http://yogh.io/#tx:raw:01000000016d5412cdc802cee86b4f939ed7fc77c158193ce744f1117b5c6b67a4d70c046b01000 0006c493046022100be69797cf5d784412b1258256eb657c191a04893479dfa2ae5c7f2088c7adb e0022100e6b000bd633b286ed1b9bc7682fe753d9fdad61fbe5da2a6e9444198e33a670f012102f 0e17f9afb1dca5ab9058b7021ba9fcbedecf4fac0f1c9e0fd96c4fdc200c1c2ffffffff0245a87e db080000001976a9147d4e6d55e1dffb0df85f509343451d170d14755188ac60e31600000000001 976a9143bc576e6960a9d45201ba5087e39224d0a05a07988ac00000000 It'll parse non-existent and network-invalid transactions just fine, so long as the format is correct, like this one with version number #5, which is pretty cool: http://yogh.io/#tx:raw:0500000001C997A5E56E104102FA209C6A852DD90660A20B2D9C352423EDCE25857FCD370400000 0004847304402204E45E16932B8AF514961A1D3A1A25FDF3F4F7732E9D624C6C61548AB5FB8CD41 0220181522EC8ECA07DE4860A4ACDD12909D831CC56CBBAC4622082221A8768D1D0901FFFFFFFF0 200CA9A3B00000000434104AE1A62FE09C5F51B13905F07F06B99A2F7159B2225F374CD378D7130 2FA28414E7AAB37397F554A7DF5F142C21C1B7303B8A0626F1BADED5C72A704F7E6CD84CAC00286 BEE0000000043410411DB93E1DCDB8A016B49840F8C53BC1EB68A382E97B1482ECAD7B148A6909A 5CB2E0EADDFB84CCF9744464F82E160BFA9B8B64F9D4C03F999B8643F656B412A3AC00000000 The mining simulator (keyword 'mine'), defaults to simulation mining on top of the tip of the chain: http://yogh.io/#mine:last and (secretly) on top of any block you like: http://yogh.io/#mine:height:0 http://yogh.io/#mine:height:200000 This simulator is mostly a gimmick that's fun to look at, but may be useful for educational purposes. There's also support for script interpretation and execution: http://yogh.io/#script:id:6b040cd7a4676b5c7b11f144e73c1958c177fcd79e934f6be8ce02c8cd12546d:1:493046022100be69797cf5d784412b1258256eb657c191a04893479dfa2ae5c7f2088c7adbe0022 100e6b000bd633b286ed1b9bc7682fe753d9fdad61fbe5da2a6e9444198e33a670f012102f0e17f 9afb1dca5ab9058b7021ba9fcbedecf4fac0f1c9e0fd96c4fdc200c1c2 ==== Implementation The web application is a GWT (Google Web Toolkit) project that's patched into, essentially, a JSON-RPC proxy for a Bitcoin Core node. The proxy can be configured to reach out to Blockr's API (and others) if you aren't running a node, although it's always nice to use your own node instead. The proxy will only request the node's getblock, getblockhash, getbestblockhash and getrawtransaction methods. It constructs (if needed) and forwards raw transaction and block data which will be interpreted locally on the client (in the browser). It'll run in any J2EE web container when built as a .war file. ==== Contribute This project got some funding a few months ago which allowed me to host it on multiple nodes. Huge thanks to Jameson Lopp for this. I encourage anyone who would like to contribute to further development of this explorer. The project could do with some testing, code reviews, dots on the i's, lots of feedback, suggestions for new features, help coding, independent hosting, translations. More eyes looking at it would be good. Here's a way to donate: http://srv1.yogh.io/#contribute: ==== Let me know what you think!

Bitcoin / Bitcoin Discussion / Re: [ANN] Bitcoin blockchain data torrent

on: October 03, 2014, 12:03:52 PM

I was updating from the 16gig bootstrap to the current (21gig) torrent and noticed they don't go side by side initially (ie. the 21 gig one doesn't start off from where the 16gig one stopped). I deleted both torrents (not the actual bootstrap file) and loaded the 21 gig torrent by itself, it (uTorrent that is) started checking the file as I would expect, but then started downloading from 0%. I expected it would start downloading right around 70% or so. Is this expectation wrong? Or did I do it wrong? TLDR; How do I update the torrent to a more recent version without downloading from scratch?

Bitcoin / Development & Technical Discussion / Re: Feature Request for Bitcoin Core: Replace by Fee

on: August 06, 2014, 10:43:43 PM

Quote from: BitcoinGirl325 on August 06, 2014, 10:00:18 PM Linux - never made it to mainstream users. The general public uses OS X. You should know how many times you use linux or take advantage of Linux each and every day without you even knowing it. Quote from: BitcoinGirl325 on August 06, 2014, 10:00:18 PM Firefox - surpassed in usability and security by Safari and Chrome. Apple's new web services don't even support Firefox anymore. You mean chrome, the browser built on top of the open-source chromium project? Quote from: BitcoinGirl325 on August 06, 2014, 10:00:18 PM Wordpress and MySQL and Apache - arguably the 3 open source technologies that made it to mainstream users... BUT both are maintained & controlled by corporations (Wordpress and Oracle and Apache). Hence their success. Without these corporations funding the development of those products, they would likely not have taken off. Sure, but take PostgreSQL, open-source database system I'd venture to say is better in many ways than MySQL (and also many proprietary database systems). No major corporation there. Wordpress -> Drupal (no corporation, less popular but still in the loop). Apache -> Apache is a foundation. Quote from: BitcoinGirl325 on August 06, 2014, 10:00:18 PM VLC - surpassed handily in functionality & features & ease of use by companies like LogMeIn. VLC stopped evolving years ago. VLC is an open-source media player. LogMeIn is remote control software. You were thinking of VNC I guess? VNC (which is just a system describing server-client interaction to share a screen, basically) includes all features software like LogMeIn or TeamViewer has, but it doesn't have a whole lot of applications that 'present it nicely'. I'll give you that. VLC on the other hand is one of the best media players to roam the earth. Quote from: BitcoinGirl325 on August 06, 2014, 10:00:18 PM The other technologies you've named: not being used by any mainstream users, unless they were taken over by a corporation (e.g. how Apple used BSD for OS X). Quote from: BitcoinGirl325 on August 06, 2014, 10:00:18 PM I would LOVE for Bitcoin to go mainstream. I'm rooting for Bitcoin. But unless a for-profit corporation starts controlling & writing the code, it's looking increasingly unlikely that Bitcoin will go mainstream. You must understand this directly contradicts everything bitcoin stands for? Quote from: BitcoinGirl325 on August 06, 2014, 10:00:18 PM The few developers working on the code can't even agree on a direction for its future! It's taken 5 years to get where we are today, which is... almost no progress. The Bitcoin Core client hasn't even reached version 1.0. My good lord. 1. Core developers, and the bitcoin community as a whole, are very rightly conservative when it comes to making decisions about bitcoin's future. If everyone would agree in a heartbeat I'd say something is quite wrong. 2. 5 years is almost no time at all. And to say there's been almost no progress? Are you kidding? 3. The core client will go to version 1.0 when it's good and ready. Quote from: BitcoinGirl325 on August 06, 2014, 10:00:18 PM On the other hand, for example, look where Apple has come in 5 years with the iPhone: 5 major iOS releases, hundreds of millions of phones sold, rock solid stable OS with no security flaws, an entire worldwide ecosystem built around it. Yes. Yes. Apple has in 5 (more like 30) years managed to become the crappiest company in the world by building a computer and a phone. Your definition of mainstream is just wrong.

Bitcoin / Development & Technical Discussion / Re: Feature Request for Bitcoin Core: Replace by Fee

on: August 05, 2014, 10:55:43 PM

Well on the flip side, banks also wouldn't carry your money from A to B if they didn't get payed for it. So there's that. And BC.I isn't in theory preventing this transaction from happening; it's actually encouraging it by trying to get it to a miner, which it's failing at for obvious reasons. On the other hand, wallets are preventing you from double spending the transaction because BC.I appears to be persistent on relaying a doomed transaction, so in practice, it is preventing you from moving the funds - even if through another transaction, indirectly. Rest assured all these 'irrelevant usability issues', as myself and many developers would call them, will be worked out before long.

Bitcoin / Development & Technical Discussion / Re: Feature Request for Bitcoin Core: Replace by Fee

on: August 05, 2014, 08:23:05 PM

I must say I'm surprised this transaction is still being propagated. Seeing that it has no fee, I see no reason for nodes to relay this transaction for longer than a few hours, if at all. If it hasn't reached a miner that's prepared to mine it by that time, it likely never will.

Alternate cryptocurrencies / Altcoin Discussion / Re: Sidechains, Treechains, the TL;DR, welcome to join discussion.

on: August 05, 2014, 09:51:24 AM

Quote from: ex0du5 on August 04, 2014, 10:15:31 PM Quote from: adam3us on August 04, 2014, 02:33:57 PM Quote from: ex0du5 on August 04, 2014, 05:12:24 AM You have an entity that takes value into it's store and gives out value in an alternate blockchain that may or may not follow similar rules (some altcoin, maybe a Bitcoin clone or maybe something quite different). The exchange can hold onto that value until the altcoin work is done and exchange back the value. Validation is done in whatever currency is chosen for the transfer, which can obviously have any of a variety of zero-knowledge transaction and block validation schemes. that sounds rather centralised? Dont forget MtGox also operated like that - they exchanged your bitcoins for gox iou entries in their database. Then some stuff happened (you trade etc) and finally you ask for repayment of the iou. If its central there is a central point of failure that can lose or steal the backing funds. You can think of a sidechain as a decentralised escrow agent where the sidechain economic majority (hashrate etc) controls and fairly administers the backing. Adam I didn't think of it as centralized because anyone can be an exchange and whoever wants the branch can choose the exchange. Also, the choice on whether to peg the conversion or let it float is an option of the exchange and it's store. But I understand that this forces openness on a not-necessarily-open process and standardizes for a particular use. And I can certainly see the benefits of distributed administration of the backing (though would still point out that such an implementation of an exchange is not prohibited either). I think, though, it's important for me to better understand the proposals here before appearing to suggest that existing practices solve the use cases. I was just trying to get a feel for what they were targeted at solving, and your answer is a good start! Centralized in this sense means you need to trust and give responsibility to a single party that needs to play by the rules. Many-a-time it's profitable for such a party not to play by the rules, or they're compromised, and therefore it's unsafe to assume they do. Ie. Gox. Or banks. And altcoin exchanges.

Bitcoin / Development & Technical Discussion / Re: Feature Request for Bitcoin Core: Replace by Fee

on: August 04, 2014, 08:12:21 PM

Nothing is permanent in bitcoin, and a transaction that's not accepted or propagated by miners and 'lost in limbo' is, with increasing probability, headed toward the opposite of permanent. Getting the move of funds to go through should be as simple as backing up the wallet, importing it into another (more proper) wallet app and sending a new transaction with a fee attached. Or maybe deleting the cache of the iOS wallet app could work, but I have no idea how iOS or any of their apps work, so be sure to have a backup anyway.

Alternate cryptocurrencies / Altcoin Discussion / Re: Sidechains, Treechains, the TL;DR, welcome to join discussion.

on: August 03, 2014, 06:54:00 PM

I'm having some trouble fully understanding treechains and I'll be spending some more time researching its full extent, but I think I get the gist of it. It feels like the better way forward. Anyway, here's my thoughts. -- It's important to realize one of the most important reasons that make bitcoin work, is the fact nodes and miners must be aware of 'at least most things' that are happening in the network. It's also important to realize one of the most important reasons bitcoin is hard to scale and (dare I say) 'fat', is the fact nodes and miners must, again, be aware of 'at least most things' that are happening in the network...... It's kind of crappy both those reason are the same. I venture to say treechains are the superior scaling solution. Ie. allowing nodes and miners to be unaware of 'at least some things' that are happening in the network, without making it less secure and at the same time making it more flexible, more scalable and less fat? Sounds good to me. Sounds like the internet. Now, I'm not saying bitcoin with just a vanilla blockchain cannot scale to a transaction frequency of say, 250k/sec, I'm saying that would be very hard. And yes, 250k/s may be orders of magnitude greater than Visa's puny (4k/s?) fiat network, and greater still than what we could even hope to require at this point in time, but that's exactly the magnitude the bitcoin community should be concerned with scaling to in the future. I think that may have been a key difference of opinion in the discussion between PT and GA following PT's initial tree chain description in the mailing list. Don't be the guy that goes down in history saying: Quote from: Random Early Bitcoin Enterpreneur "4k/sec transactions ought to be enough for everybody."

Bitcoin / Development & Technical Discussion / Re: Is this transaction spendable?

on: July 30, 2014, 02:32:22 PM

I'm curious though. Can anyone think of a script that uses the altstack and can do something no other script can?

Bitcoin / Development & Technical Discussion / Re: Creating a 2-3 MultiSig address from server script

on: July 22, 2014, 12:52:08 PM

A user shouldn't send anything to such an address unless it knows all participants have their public key in there. In other words, ideally, user A needs to somehow communicate with user B and verify the keys are correct. If you, as a mediator, have sole knowledge about the public keys of the other participants in a transaction you are supposed to mediate, you are not a mediator but a mere proxy which requires trust not to fuck up.

Bitcoin / Development & Technical Discussion / Re: Is this transaction spendable?

on: July 21, 2014, 10:00:17 PM

In the code linked in the previous post, I found this (https://gitorious.org/bitcoin/luke-jr-bitcoin/source/5f8e7180c4b34d5f46c61a6dd2242f4249b5f79a:src/script.cpp#L453): Code: case OP_FROMALTSTACK: { if (altstack.size() < 1) return false; stack.push_back(altstacktop(-1)); popstack(altstack); } break; ~~//Edit: Wrong~~

Bitcoin / Development & Technical Discussion / Agents - Autonomous programs / DAC - a communications exchange format?

on: July 21, 2014, 03:46:18 PM

Hey folks, I've been wondering about the current state of development on the Bitcoin Agent / Decentralized Autonomous Corporations concept - https://en.bitcoin.it/wiki/Agents TLDR; - Is anyone working on, or are there any proof of concepts / drafts out there, for a somewhat-universal and extensible API/communications protocol over which agents can communicate with each other? Discover their services, set up an agreement, exchange signatures, construct a transaction. Something like an 'Agent Exchange Format'. I feel it's necessary to have some sense of consensus in- or direction to an exchange format of some kind in order for this concept to flourish, but I'm currently unaware of any development toward it. Take this overly modular example: Agent A_self - providing an arbitrary service to sustain itself, wishes to replicate/update itself (create a child) onto a server hosted by Agent H_host. Agent A's source code is hosted on some trusted repository. Agent A will communicate with various other agents in order to get this done, basically doing nothing itself except for negotiating with other Agents. My thinking is this (please, disregard any trust issues that arise from this flow as 'resolved'; not relevant for what I'm getting at): - Agent A contacts Agent B_builder, a service that builds a program from source and returns the resulting distribution, they negotiate a contract, deciding on a price for this service - and optionally employ some oracle/escrow service (also an agent - Agent O_oracle) to mediate the contract and verify the distribution output. A hands B the repository information, B starts building. - Agent A is now in possession of a verifiably valid and freshly built distribution of its source code. - Agent A contacts Agent H, the hosting corporation, to buy server time / space where its distribution may live, negotiating a contract, deciding on the pricing. They set up a micropayment channel to pay for cpu-time and storage space. This is mediated by Agent E_escrow and/or Agent O_oracle. - Agent A contacts Agent D_deployment, a service which deploys programs to a server, again mediated with an escrow/oracle agent. Agent A hands it the distribution which is then deployed on the server hosted by Agent H. Another instance of Agent A now lives on some server, and the process is fully orchestrated and taken care of by agents. -- Now, for the communications exchange format. Basically, what all the above agent communication boils down to is these 3 requirements: - Understanding the meaning/function of another agent's services. - Negotiating a contract between 2 or more agents for an arbitrary service. - Discovery of agents providing said arbitrary services. The first can/should(?) be programmed into an agent, I reckon. Rather trivial at this point. The third... Let's leave this in the open for today's discussion and focus on an exchange format. The second is what I'm interested in. An exchange format. All negotiation depends on some exchange format all agents involved understand. They need to speak the same language in order for them to negotiate anything. So I'm wondering whether anything like this has already been created, is in development, whether anyone's interested in seeing this happen, or whether the communication flow described here is completely outdated / entirely false? When a (however simple) exchange/communications format exists, I reckon we can start building/testing agents 'in the wild' that can communicate with each other, negotiate, transact, live, replicate, and build the concept further from there. Thoughts? Thanks.

Pages: [1]