Hi all,

I created a simple website which allows to lookup any unspent output from every address:

http://redeem.bitwatch.co/

Furthermore a raw transaction can be created which collects and combines unspent outputs whereby outputs from multiple addresses can be used.

The most important feature: standard multi signature outputs are included and it's very easy to redeem Mastercoin or Counterparty dust.



The basis for this was sipa's awesome address indexed Bitcoin branch which received some further additions.

Please note: this is experimental and feedback is appreciated.

Please RawDog, I think you're also exaggerating. Unless this discussion gets on a level worth of a discussion I'd appreciate, if you both step a step back and I think the point was made pretty clear earlier.

What's everyone's opinion about MaidSafe and SafeCoin? It was all over the news a few days ago.

http://www.safecoin.io/
https://github.com/maidsafe/Whitepapers/blob/master/Project-Safe.md

This thing looks nice. Is this is (real) prototype picture?

So AM is selling containers!

Could you please elaborate on what this statement is based?

I think your premise is flawed and using the phrasings "exploiting" and "no right to" is blatantly rude in my opinion. This is similar to "I don't like TraderTimm spending some coins and therefore I claim it's abuse of the blockchain and he has no right to do so".

As far as I can see Mastercoin acts proactive by using redeemable multi signature outputs to lower the impact on the UTXO whereby more than 65 % are already redeemed based on the data I fetched earlier to evaluate the impact of metacoins. I'm currently working on a simple website which will allow users to lookup unspent outputs of any address to push this number even higher. The whole concept of the distributed exchange is furthermore designed in a way to please miners as much as possible: to combat disruption of the market by users who accept orders but don't pay (which makes the orders unavailable until this accept order times out), a special fee is required which goes directly to the miners to make it expensive to behave malicious. On top: many Mastercoin transactions were sent with a somewhat-higher-than-usual fee to offer an additional appeal to mine MSC transactions.

I would love to hear your feedback and I'd appreciate, if you could name the issues you are seeing, so potential flaws - if there are indeed any - can be optimized.

The MSC faucet runs on a 1 GB RAM Ubuntu 12.04.4 x64 node with bitcoind 0.9 without problems and 60+ connections for a few months now. 512 MB were too little and resulted in random crashes.

Awesome!

By the way, did the foundation found a web dev in the meantime for Omniwallet?

20 GB compressed, about 112 GB uncompressed database:

http://dumps.webbtc.com/bitcoin/

Infos:

http://www.reddit.com/r/Bitcoin/comments/1zf0tu/blockchain_analysis_basics/

What I extract from this statement are three properties: validation, merge-mining and using a side chain. Could you please outline what you are referring to by validation in this context? Thanks.

It's an enhancement and not a threat. You need to differentiate a few things: there are protocols like XCP and MSC and there is some kind of communication with the Bitcoin protocol, for example the initial proof-of-burn (XCP) or fundraising-for-dev (MSC), the several data-storing schemes like using multisig transactions to encode transaction information or the DEX which directly interacts with the Bitcoin layer. It appears they are building the groundwork for an even more frictionless communication between Bitcoin and X.

Sorry for repeating myself, but this is a misbelief. Or let me rephrase: it's only an issue, because the XCP wallets don't use unconfirmed inputs.

But you actually don't need to do this. Using the output of a freshly created transaction and the chaining of unconfirmed transactions has the same effect, no delay and doesn't create so many entries in the UTXO set.

The only potential grey case is a break of the chain due to malleability. But with the latest changes this shouldn't be an issue at all.

How about you go ahead, collect shares and start a passthrough? Forcing anyone who holds direct shares to use XCP is not feasible.

Hey, they are small..

Ubuntu 12.10 x64

You actually don't need to do this. Using the output of a freshly created transaction/chaining unconfirmed transactions has the same effect, no delay and doesn't create so many entries in the UTXO set.

The only potential grey case is a break of the chain due to malleability. But with the latest changes this shouldn't be an issue at all.

"Many unspent outputs are bad!"

What is "Primed"? Related to "Pending priming for My Address #2 for 10 more unspent outputs".




Edit: Ah, it creates unspent outputs:

https://www.biteasy.com/testnet/transactions/221acd85e4dcb320793c7baa4d1fde73bf8a53618011f81702e688e3e3af52b0

Nevertheless I'd appreciate, if someone could please explain the purpose of this. It creates outputs and I assume this is done to have "free outputs" available. But what's the actual benefit in contrast to chaining unconfirmed transactions? They are most likely included in the same block anyway?

Are you willing to sell the domain? Please contact me via PM, if you are. Be ready to provide some proof of ownership.

Thanks for the reply. So the user actually chooses where his files are hosted or the amount of bandwidth? And to provide a high probability of availability there are several copies of a file in the cloud and nodes constantly confirm the availability and initiate replication in the case a mirror goes down?

I'm really looking forward to this project and wish you all the best!

Please don't get me wrong, I also read your posts in the other thread, but I think using some altcoins as reference to back up this statement is not enough. Only because there were no visible consequences in a smaller environment over a limited amount of time doesn't guarantee it would carry "no risk" to the network. From the other thread:


Now let's look at the actual time between blocks: it's somewhere around 7 minutes (actually 7.98 min at the moment) due to the increasing hashrate and with even lower times during peaks. With a halved block time the time between blocks would therefore reduced to times of somewhere around 3.5 minutes. Indeed not much of headroom. Risks aside, it would also increase the overhead whereby this primarily affect thin clients.

At least in my opinion - the benefits of a slightly reduced block time are marginal. 5, 8 or 10 minutes is somewhat similar and not much of a difference. 5 minutes are still way too long for use-cases in which any delay longer than a few seconds naturally becomes a burden, e.g. paying a drink at the bar. Sure, it would be nice to wait a little less, but it doesn't provide a real solution for the underlying problem.

I'm in favor of finding alternatives instead of using quick fixes.

Installation was smooth but the error remains:


In the meanwhile I was able to set up a working sx with the following script:

https://github.com/mastercoin-MSC/install-msc/blob/master/res/install-sx.sh

Which seems to use the following commits:

https://github.com/spesmilo/libwallet/commit/21447cc
https://github.com/spesmilo/libbitcoin/commit/335489f
https://github.com/spesmilo/obelisk/commit/58f326d
https://github.com/spesmilo/sx/commit/a97f7be