Last year I was working on a new sort of blockchain that would enable instant transactions. I'm dumping some info here so it's searchable and maybe inspires someone or w/e.

The basic idea is that each TX has a small PoW attached and is 'mined' instantly. Larger miners (who are in it for the money) mine TXs with *large* PoWs and point back to other 'work heavy' blocks but also link back to these 'lighter' txs from regular joes.

The blockchain is actually a DAG instead of a linked list.

One challenge was ordering txs, I think I've come up with a pretty good solution that's included in the source here: https://github.com/XertroV/quanta-test/blob/master/quanta.py#L204. Basically it recurses down the heaviest path until it reaches a common point between all paths, then it recurses down the second heaviest path till it hits a block in the first path, and so on down all paths. In this way it can operate as a DAG, has a deterministic ordering, and not worry about people inserting blocks into history or anything like that (though there might be a DoS angle here on computationally heavy re-orgs).

It relies on treating the pool of workers available as producing a *stream* of work, rather than the discrete blocks that we're used to. By treating it as a stream you get (nearly) infinite granularity, enabling near instant TXs. You still have to wait an hour for a good confirmation, though (like all networks).

One downside is all TXs have lots of metadata about links so they can be 500 bytes for a simple TX.

Source code is here: https://github.com/XertroV/quanta-test

I can't remember if it works or not when you run it.

[RFC / Whitepaper (Github)]

Marketcoin Announcement Thread

Links

• RFC Topic: https://bitcointalk.org/index.php?topic=598784
• RFC / Whitepaper (Github): https://github.com/marketcoin/marketcoin/wiki/RFC
• Marketcoin.org: marketcoin.org
• Eudemonia Research: eudemonia.io

Announcements

• 07.05.14 RFC Posted https://bitcointalk.org/index.php?topic=598784

[[RFC] Marketcoin - A web of distributed markets with a common unit]

[RFC] Marketcoin - A web of distributed markets with a common unit



Abstract

Decentralised currencies have become a recently realised reality; e.g. Bitcoin, Peercoin, Mastercoin, and Nxt. However, despite their variety in both design and philosophy, there does not yet exist a decentralised market in which these can be traded effectively. Just as Bitcoin should enable new economic structures because it significantly improves over the previous best system, a market with similar properties (say virtually zero fee) may provide new insights into price finding and market dynamics. We present such a market in this paper, along with an experimental method of evaluation with novel properties that may help mitigate sticky prices and thus enable smoother price finding and dampen the intensity of corrections. As a benchmark, a successful decentralised cryptocoin market is required to be able to replace an exchange such as cryptsy (in the case of crypto-crypto pairs).

Full RFC / White paper work-in-progress: https://github.com/marketcoin/marketcoin/wiki/RFC

Please feel free to quote parts of the document here if you wish to discuss them specifically.

[have the same economic implications]

It occurred to me that Proof of X realistically only requires a sacrifice that anyone can make (or at least a large enough subset of users). For example, PoW uses energy, PoS uses coindays, and PoB uses coins.

There's a fourth option I'll call Proof of Deposit. Basically you just lock your coins up for some particular length of time (like 20 weeks) and you're paid a bit for it. Technically this is similar to PoS/PoB (all three have almost the same economic implications) but provides more information to users at the expense of impulsive (but costly) attacks.

PoS destroys coindays, PoB destroys coins, PoD removes control of disbursement for some time.
Economically in all three cases coins are removed from the supply for some time and then reintroduced at a later time. In the interim all other coins should appreciate slightly in value. After that time has elapsed the miner is given a little reward and her coins back as thanks for making everyone a little wealthier for a bit.

The easiest way to manage this (from my perspective) would be to require each coinbase tx to have the following:

Code:

Inputs: X coins where X is the difficulty parameter, signed
Outputs: 1. Block reward to arbitrary key
2. Output leading back to owner for X after some time.

scriptPubKey for 2 might look like:
_OUTHEIGHT _INHEIGHT <depositTimeInBlocks> _ADD _GREATERTHAN _IF
     (back to owner)
_ELSE _RETURN _ENDIF

OP_OUTHEIGHT pushes the height of the tx spending the output to the stack (IE most recent block, for all intents and purposes)
OP_INHEIGHT pushes the height of the block the tx was included in to the stack

I think it's important to stress that PoS/PoB/PoD have the same economic implications but different psychological implications.

For a blockchain to internally fuel itself there must be some internal resource which is sacrificed. Ultimately the only internal resources we have to sacrifice are the coins themselves, so it should come as no surprise that PoS/PoB/PoD look the same from a macroscopic perspective.

[Note:]

Note: I've left some comments at the bottom.


Introducing Factum Money

Bitcoin is a disruptive technology, and since time immemorial disruptive technologies have challenged our existing theories and demanded improvement. I’m not going to beat around the bush trying to make Bitcoin conform to our existing schemas. We need to rethink what makes types of money that particular type; not look into why Bitcoin can function as a currency – that is already well understood. I’ll outline what I think are the important constituents of money that help differentiate them today. We’ll then look into how Bitcoin fits in, hopefully in such a way that convinces you Bitcoin is truly novel.

Broadly, the three well understood forms of money are as follows: fiat money, commodity money (CM), and commodity-backed money (CBM). People will often separate the former with the latter two based on the notion of ‘intrinsic value’. While we can agree that all three have value, we also know that the property of non-zero value fiat money holds is derived from legislation: not an intrinsic property.

While this categorisation schema works for the above, I believe there is a more pertinent distinction to be made: that of non-monetary use-value; i.e. the money type in question has some primary purpose other than to simply exchange value between parties. The primary use of fiat money is to exchange value, we can therefore see that not only does fiat not have any non-monetary use-value, but that the use-value of fiat money is fundamentally bound to the exchange-value. On the other hand, we see that CM and CBM derive their use value not just from exchange, but also from the intrinsic properties of the commodity itself. Therefore we can categorise these three forms of money as before, but with the determinant being non-monetary use-value.

The second property I’d like to introduce is the concept of ‘deferred value’, and ‘direct value’. Ultimately you can think of these as ‘an IOU’, or ‘not an IOU’ respectively.

Deferred value is seen in both commodity-backed money, and fiat money. Both are not so much valuable because of what they are, but because of what they entitle the user to. This is easy to see in the case of commodity-backed money, such as a gold certificate, as it is redeemable for a commodity (in this case, gold). However, in the case of fiat money, it is not directly redeemable for any particular commodity, but is legislated that it has value (though not the magnitude of value). Put in another way: fiat money entitles the user to some value. We should consider that if the legislatorial environment surrounding either of the above were to collapse, they would respectively become useless. Commodity money can never truly reach zero value, but both CBM and fiat can, and so participating in such systems is like passing a hot potato; it’s okay as long as you’re not the one to get burnt. This is part of the nature of deferred value.

On the other hand, direct value implies that the received value is intrinsically tied to the received object. In the case of commodity money – say, rice – it is trivial to see that the use value of rice (that you can eat it) is bestowed to the recipient immediately upon receipt.

By viewing the property of non-monetary use-value in light of deferred or direct value, we can see that while a gold certificate may have no particular non-monetary uses in and of itself, by acting as a method of deferred value it can inherit non-monetary use value from the commodity it is tied to.

As a visual summary, here is what we’ve talked about so far:



Enter Bitcoin: the rule breaker, the status quo usurper. You might have noticed there is one particular combination of the above properties that has not been covered by traditional monetary systems. It’s tempting to fill in the blank with Bitcoin; but we should remember that Bitcoin is merely an example of this missing puzzle piece, just as the US Dollar is just an example of fiat currency.

Definition: Factum Money
A stand-alone money system in which each unit, by its intrinsic properties alone, necessarily holds a non-zero value.

Reason for choice:
Factum loosely translates from latin as ‘done’; a play on words, as fiat loosely translates as ‘let it be so’.
Factum also lends itself to ‘fact based currency’: because of each individual’s knowledge of the system, it is able to be used to exchange value; an appropriate description.

To gain an intuitive understanding of what this really means, let us diverge from the topic for a moment to discuss aliens. (Bear with me!) It’s an assumed property of the universe that no matter where you are spatiotemporally the number pi will be constant. You can express this in various ways; but the simplest is that the ratio between the radius and circumference of a perfect circle is always constant. I suggest that Factum Money has a similar property: that regardless of position in space and time, society, culture, species, or any other physical differences, true Factum Money is able to transfer value. Doubtless each instance of factum money can have local environmental factors that prohibit its use; Bitcoin is known to lack quantum computing resistance, and would fail if SHA256 is broken, just as Litecoin relies on Scrypt. However, due to the particular conditions of today, Bitcoin is able to transfer value, and holds the mantle of ‘Factum Money’.

Filling in the blank, we now we have a table that looks like this:



There’s a great deal left to explore within this idea; of particular interest (which I’ll explore in a follow up post) is what this actually means for Bitcoiners, and how we can predict and take advantage of this model. Cryptocurrency has many facets that have so far only been theoretically explored, in particular perfect money laundering, and distributed exchanges. I’ll largely be exploring distributed exchanges in my next post.


I originally wrote this in August and am looking for feedback. I've written most of the next section that discusses exchange and distributed exchange (and going into some pretty significant detail about cross-chain trade and how to structure it technically and economically).

This was originally posted here.

Hi All,

Bitcointalk lacked an ANN thread for the Bitcoin Association of Australia, so this is it.

You can find more information at https://bitcoin.asn.au

We're affiliates of the Foundation and so share membership. Australian members of the Foundation are members of the Bitcoin Association of Australian and vice versa.

We're establishing ourself currently, and are actively looking for those who are interested in getting involved.

If you've any questions, feel free to ask!

Cheers,
Max

BitcoinAutoNode.sh is a script designed for fresh, cheap Ubuntu VPSs to change your root password, and then automatically enable a firewall, update the OS, include ppa:bitcoin, install bitcoind, set bitcoind to start on reboot, and then reboot.

I'm posting it here with the hope that someone finds some use for it.

https://github.com/XertroV/BitcoinAutoNode

[Marketcoin:]

I will attempt to describe Marketcoin below. The idea is in its infancy and will probably require great adjustment (as well as making some protocol decisions) before it is viable (if ever).

This describes Marketcoin, what I plan to become a P2P Trustless Cryptocoin Exchange. I suggest units be called named 'kets' (eg. milikets, kilokets, etc; similar to the colloquial milibit).

I can't think of any flaws just yet, but I don't describe much of the protocol here. Notably, an exchange matching system is required. I'm quite fond of batch trades at every block production for the currency pair (will explain more on that later) which appears to have a trivial application in a blockchain. This can be a 'discreet double auction' style system easily, which also appeals to me. Having an open and free exchange which is liberated from the burdens of HPC and buy/sell wall manipulations is something I (and hopefully many others) would happily use.

There is a lot of room for discussion and improvements, beyond the idea presented below.

I will refer to the buyer and seller throughout this. This particularly refers to the buyers and sellers of Marketcoin, if not otherwise specified. Their public keys are respectively Pb and Ps. In addition, Altcoin will be a general term used to describe a currency such as Bitcoin, Namecoin or Litecoin.

Marketcoin:

This idea rely's on the same private key generating the same public key in both cryptocoins. One of these cryptocoins will always be Marketcoin. (A Many->One and One->Many relationship is far easier to manage than Many->Many)

If you'd like an example, load up bitaddress.org and liteaddress.org and test these two example privkeys:
BTC: 5KWWbi82n63rdf8Y78N4YnntYUmtHJCodU3SpYFRQenRSSCktS2
LTC: 6vpF4qfZgWWj732PcxA2LBa4VxLMV6eqQ9ScXjGT87738LKdmPV

Note both these privkeys show identical pubkeys.

Marketcoin is a Bitcoin-like system, however, transactions are drastically revamped, as well as the data stored in, and the mechanisms behind the blockchain. Bitcoin is a comparably simple system; there is one ledger and it must do no more than ledge. Marketcoin's blockchain will need to record transactions, and enough information to help verify those. What I will suggest is not a normal blockchain, but a hybrid, as we shall see.

In addition, those transactions must have certain properties. Their primary facility is to enable exchange of cryptocoins, not to act as a currency in their own right. Thus, transactions are not as arbitrary as traditional cryptocoin transactions. I suggest all transactions in Marketcoin be directly tied to a transaction in another cryptocurrency; with null being an option. You can think of these transactions as trades, though that is not technically correct, as it is really a conditional transaction.

Furthermore, transactions are not generated by one party, but are rather a product of the network (or the miners/auditors if you prefer). The beginning of a transaction is the matching of two orders, each signed by their respective owners. As each order is signed, the buyer and sellers' public keys are known (each corresponding private key is imported into both the Marketcoin client and the Altcoin client for the respective party).

I suggest transactions be necessarily 2-staged, in the following way:

• To begin with, an order is broadcast, once it is matched (included in a block) the combine to form a transaction which is confirmed but not finalised. This transaction is Ps -> Pb.
• At this point, to finalise the transaction, a signed transaction for the agreed amount from Pb -> Ps on the Altcoin network must be broadcast within the Marketcoin network. Furthermore, it must have been included in an Altcoin block produced prior to the Marketcoin block it appears in. The Altcoin block's hash should be included.
• Once this condition is met the Ps -> Pb transaction on the Marketcoin network becomes finalised, and the buyer can trade their marketcoins for whatever other cryptocurrency they please.
• If this condition is not met after 24 hours in blocks (144 blocks on the Bitcoin network) the transaction is reversed and the marketcoins are spendable by the seller once again.

This has some distinct advantages:

• Once the order is matched, the trade is out of the seller's hands. Furthermore, the buyer must prove payment before finalising the Marketcoin transaction, but whether the trade is completed is entirely within their hands. However, this does raise the potential for abuse.
• Transactions on Altcoin networks just need to be standard transaction; no changes are needed to Bitcoin or other cryptocurrencies to trade with Marketcoin.
• Fees are possible on both ends of the transaction, and the buyer pays if they have a big altcoin transaction.

Though it has some disadvantages:

• As mentioned, the potential for a DoS by a malicious party matching orders but not fulfilling trades. There may be some way to get around this using coin-age on the altcoin network (Proof of Stake), or setup a reputation measure based on passed unfulfilled trades.
• Marketcoin could not trade with Alt-Marketcoin as proof of payment is required as part of the protocol. The easy workaround is to detour through Altcoin.
• Difficult to charge a fee for placing an order to buy marketcoins. Perhaps a fee can be optionally included, and then once someone has marketcoins they can easily place buy orders with minute fees. It might be a little difficult initially, but once you have marketcoins it should be easy.
• As we rely on transactions from other cryptocoin networks, a block reorganisation on those networks could have disastrous complications for Marketcoin. There must be significant buffer (at least 6 blocks / 1 hour) and appropriate reorganisation protocols in place to help mitigate the potential of doublespends on an Altcoin network forcing a re-organisation on the Marketcoin network. I believe this can be mitigated, however.

There are certainly subtleties I've ignored here, such as how are trades matched. There are obvious requirements, such as being completely deterministic and as fair as possible. I imagine there are a few potential systems out there but there is time still to examine that aspect.

The blockchain is rather more complicated than transactions. To remain secure a user must be able to verify that a past trade made with a cryptocurrency he does not have access to is legitimate, if done incorrectly this may compromise the fungibility of Marketcoin. Because of this transactions will somehow need to be cemented after some time to prevent trades through bogus altcoins being reversed to reverse the marketcoin transaction (and all those following). Perhaps a solution is something akin to n blocks of leeway for altcoin reorganisation, and then the marketcoin transaction becomes not simply finalised but irreversible, the marketcoins now being safe to use in another transaction. This is a matter of protocol, and will need to be investigated early on. This also ties in with requirements of age of proof-of-payment transactions included in marketcoin transaction finalisations.

I envisage the blockchain being comprised of a myriad of blocks; a different type for each currency-pair, in fact. Each type of block is mined in the same manner as the parent Altcoin (SHA256 for BTC/MKC blocks, Scrypt for LTC/MKC blocks, etc) to enable merged-mining. This will help support the security of each currency pair and the security of Marketcoin overall. Each currency pair block will have a list of all block-headers and their hashes from the altcoin not currently included in the currency pair chain, up to some maximum. This means that the Altcoin proof of work chain is included in the Marketcoin proof of work chain. This enables quick and easy transaction verification by checking the Altcoin txid exists in the claimed block (these are specified in the transaction finalisation). Merged mining is also very complementary to the validation of transaction finalisations. Trivially, the correct currency pair chain is decided by the largest total proof of work of the sum of both the currency pair blocks proof of work and the included Altcoin proof of work.

The block reward situation is a more difficult issue. My solution is as follows:

• Let all currency pairs be denoted by set C = { C1, C2, C3, …., Cn }
• The block rewards all draw from a central pool of size P, the exhaustion of this source triggers the next retarget.
• At the beginning of each retarget period, the volume of Marketcoin transacted (Sk) for each currency pair Ck, is summed to total S.
• Each currency pair has their block reward set to Sk/S*P for the remainder of the retarget period.
• Each currency pair starts with difficulty=1 and block reward=0. This is to facilitate a quick catchup period before the market 'opens' - or becomes stable. Though trading will still be possible.
• Once the market opens the reward is calculated as part of set C.
• If there is not enough left in the central pool a miner shall take the remainder and this will trigger the next retarget period.
• Each retarget period is treated to a small decrease in pool reward size, a continuous function as opposed to Satoshi's step function.

This means there is still a provably limited supply; in addition, periods of growth will be treated to faster increases in supply, providing not only economic benefit, but also reducing the maturation period of Marketcoin.

There are still possible avenues for abuse, one possible example being someone creating a cryptocoin, attempting to fake large volumes (which requires many marketcoins) of trades with consistent low difficulty, and then when the reward readjustment approaches they are able to claim a large proportion of the pool for that retarget period. There are two ways around this: the first is to make demurrage or transaction fees high enough to make such an attack unprofitable, the second is to allow users to decide which currency pairs are allowed (similar to nonstandard transactions in Bitcoin). This will need to be dealt with.

Apologies if some of this rambles a little, it's getting late here in Australia. Hopefully it's clear enough.

As an FYI, unless there are game changing issues found with this I would like to communally publish a whitepaper and begin development. I've was working on a chaintrade implementation when I came up with this.

I've set up a github repository for the Marketcoin Whitepaper here: https://github.com/XertroV/MarketcoinWhitepaper

Original Source: http://xk.io/wp/?p=6

I'm attempting to add an RPC command to bitcoind. (createchaintradetx in this case)

(Code thus far: https://github.com/XertroV/bitcoin/commit/645c88d361a18c330845e5697ea9c817045bd452)

I'd like to convert one fo the input values, and it seems there's a lot of that done in bitcoinrpc.cpp in function RPCConvertValues.

I've added the line I presume I need:

Code:

if (strMethod == "createchaintradetx" && n > 5) ConvertTo<double>(params[5]);

However, I continue to recieve

Code:

error: {"code":-1,"message":"value is type str, expected real"}

I presume the conversion is failing. I've confirmed this with a previous RPC command I tried to add and had the same problem.

Does anyone know why this is failing? I've grepped through for other function names (such as createrawtransaction) and can't find other references to them that would hint at what is needed to fix this.


Edit: as a testcase to produce the above error, if you clone the chaintrade branch linked above, you should be able to compile and run the following on testnet:

Code:

b-test createchaintradetx 7415e100520c4fc2de9429958c0b64500a076b48ef2ad0648c7243c52046c671 2102c1acc4dd7c5b43eee5626dbf0349095bfc85f16ce8dcf48025a0c0ef93c2644a 7415e100520c4fc2de9429958c0b64500a076b48ef2ad0648c7243c52046c671 2102c1acc4dd7c5b43eee5626dbf0349095bfc85f16ce8dcf48025a0c0ef93c2644a 5b50d05942cc2b5f65bbe4077e35e968cb743faad20910e02a26becf87e05f2a 1

I've been thinking recently about the potential applications for pegged cryptocoins. The setup would be something like this:

• A Transparent Not-for-profit creates a new cryptocurrency and premines ^[1] a great deal of coins, hundreds of thousands or millions of units.
• They maintain control over the cryptocurrency.
• They exchange 1 AUD (australian dollar) for 1 AussieCoin (or whatever it's called). There may be a small fee (0.5% or something, to support the organisation).
• They maintain a 1:1 reserve of distributed AussieCoins to AUD held. This allows the currency to remain pegged and can guarantee their 'value'. ^[2]

We now have a cryptocurrency that can easily work as Bitcoin does, but is intrinsically linked to the Australian Dollar. ^[3]

Why is this important? Once we're in Cryptocurrency-land, issues we have now do not apply. We can easily exchange one cryptocurrency for another with little issues of trust and fraud. (As transactions on both chains are irreversible). The most crude (safe) implementation would be using a 3rd party to hold coins from both chains in escrow. Once they are confirmed, the two parties can exchange. If there is any issue, the escrow party has the final say on the trade.

This potentially opens up an easier supply chain for changing Fiat into Bitcoin or other cryptocoins. Furthermore, it means we have an introductory step for new users. New users may be unwilling to trust Bitcoin (a currency sans government backing and whatnot) - but it will be easier for them to trust electronic fiat in their 'native' currency.

Furthermore, with the recent FinCEN report, if a USCoin exists it may be easier and safer for a company / not-for-profit to comply with regulatory laws (since once we enter cryptoland, we leave all jurisdictions).

However, before these ideas become viable, we'll need both the exchange infrastructure and the right legal environment - which might mean needing more regulation. After all, when you try and shut something like this down, it will sprout another head; we just need the motivation.


[1] They could premine, or, for simplicity, they could simply make the first block rewards massive, and latter rewards 0. Or they could create a way to 'mint' currency on demand. The trust required for such a setup requires a transparent not-for-profit IMO.

[2] This is why they need control over the currency, how much is up for discussion.

[3] There may be issues if the free-market exchange rate differs from the pegged rate (i.e. 1:1). This is possible if there are issues with supply, or for money laundering purposes (buying off the grid and selling back to the not-for-profit).

Using Bitcoin-Qt (and bitcoind) v0.6.3 from the PPA [Ubuntu 12.04 x64].
Have tried launching a freshly compiled Bitcoin-qt also.

Despite this and a -rescan, the client doesn't seem to want to download past blk 192528

I use Bitcoin-qt just to downloads blocks with an unused wallet.dat. I run it with Armory 0.81-alpha attached.

Strangely, Armory seems to be downloading new blocks fine. It also registers new transactions (after 192528). The height currently is 192885 which matches blockchain.info.
However, from Armory I cannot broadcast transactions to the network - but only from select wallets. I presume this is because Armory tells my client that a transaction is taking place many blocks ahead (in terms of transaction balances) of where the official client thinks it could be; I cannot send coins from an address which has only received coins AFTER block 192528, however, an address which has held some value since at least block 192528 will generate an accepted transaction.

Resources I've found prior to this:
https://bitcointalk.org/index.php?topic=78307.0 [happened april 23ish]
https://github.com/bitcoin/bitcoin/pull/1196 [apparently fixed the issue]

Anyone have any ideas? I'll try not re-downloading the blockchain for a little while so any debugging/info gathering type thing needing to be done can be.

/dev/sda6                53G   18G   33G  35% /