Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Very basic blockchain-free cryptocurrency PoC in Python

github.com

Post reply on HN
Print view View original

61–70 of 72 posts

Re: Show HN: Very basic blockchain-free cryptocurrency PoC in Python

#61

Post by rebuilder »

Jabanga wrote: post #47
pollyannas wrote: post #13

So this is basically a blockchain, but with transactions instead of blocks, and diverging-then-converging graph instead of a linear sequence of blocks (like a real family graph instead of just one-parent-one-child families common in blockchains). Looks nice, what are the problems with the approach? (the paper only lists the benefits).

There is no way to have a controlled release of new coins into the system. For that you need a blockchain that establishes a consensus on time transpired and on the total economic resources being contributed (which allows the share of the newly generated coins that each participant will receive in a unit of time to be proportional to the share of the total economic resources they are responsible for contributing). Th…

The last point is contentious IMO. Why wouldn't there be a fee market with an unlimited block size? The miners would still want to make a profit, and would set fees to a level they deem profitable.

Re: Show HN: Very basic blockchain-free cryptocurrency PoC in Python

#62

Post by wildbunny »

Jabanga wrote: post #47
pollyannas wrote: post #13

So this is basically a blockchain, but with transactions instead of blocks, and diverging-then-converging graph instead of a linear sequence of blocks (like a real family graph instead of just one-parent-one-child families common in blockchains). Looks nice, what are the problems with the approach? (the paper only lists the benefits).

There is no way to have a controlled release of new coins into the system. For that you need a blockchain that establishes a consensus on time transpired and on the total economic resources being contributed (which allows the share of the newly generated coins that each participant will receive in a unit of time to be proportional to the share of the total economic resources they are responsible for contributing). Th…

I'd like to direct interested readers to a thread containing a link to a draft paper I wrote about addressing these issues in a blockless DAG based cryptocurrency:

https://bitcointalk.org/index.php?topic=1992827.0

Cheers, Paul.

Re: Show HN: Very basic blockchain-free cryptocurrency PoC in Python

#63

Post by Paul_S »

ErikBjare wrote: post #44
jchanimal wrote: post #42

Reminds me of a cryptocurrency for the gift economy that I'm working on. Each coin is unique and valued subjectively by each person. https://github.com/jchris/document-coin

Holy shit, I've had an idea just like that in the past.

I think it's a common idea. I thought of it before bitcoin was a thing (public signed transactions) and heard similar ideas many times. Still waiting for a working system because at this point in pretty sure I'll never actually create one myself.

Re: Show HN: Very basic blockchain-free cryptocurrency PoC in Python

#64

Post by flashdance »

jcfrei wrote: post #48
Jabanga wrote: post #47

Earlier quoted context omitted.

There is no way to have a controlled release of new coins into the system. For that you need a blockchain that establishes a consensus on time transpired and on the total economic resources being contributed (which allows the share of the newly generated coins that each participant will receive in a unit of time to be proportional to the share of the total economic resources they are responsible for contributing). Th…

> There is no mechanism to link cost of proof of work generated to the value being transacted. With a blockchain, scarcity of space per block leads to a fee market forming, and fees paid increasing as the value contained per transaction increases. This leads to security (proof of work) increasing in proportion to value that needs to be protected. My understanding of proof of work is that it's used to limit the number…

> If block creation intervals were lower it would compromise the security of the system and enable attacks with much less than 50% of the hash power.

Not really. The odds of an attacker successfully generating a double-spending block remain the same with a lower block interval. Many alternative cryptocurrencies have far shorter blocktimes: Litecoin has 2.5min blocktimes, and ethereum is less than 30 seconds IIRC, and they don't have problems with rampant double spends.

The problem with shorter blocktimes is that latency has a greater impact on mining profitability. A miner with a 600ms ping will lose ~0.1% of their revenue with a 10 minute blocktime, but will lose 2% of their revenue with a 30s blocktime.

This gives miners an incentive to centralize geographically to reduce their latency. No bueno!

Re: Show HN: Very basic blockchain-free cryptocurrency PoC in Python

#65

Post by Frogolocalypse »

fiatjaf wrote: post #32
bkolobara wrote: post #21

Earlier quoted context omitted.

Stellar has nice properties, like a decentralised exchange built into the platform and native integration with existing financial institutions/other cryptocurrencies through anchors. But I would not say it's blockchain-free. They close a "block" every 5 seconds. Depends on what you consider a block. They use boring stuff like PostgreSQL to store the data instead of reinventing everything.

The innovation of blockchains is not on the how-to-store-things side, but how to keep a state of things every nodes agree with. Stellar can store data on Postgres because it is just a small database of how much money each account has at each ledger. Past ledgers can be erased from the database (which makes it not a blockchain in any sense anymore). Bitcoin has a history of all transactions organized in blocks not bec…

> Past ledgers can be erased from the database (which makes it not a blockchain in any sense anymore).

A block snake? That sounds catchy.

Re: Show HN: Very basic blockchain-free cryptocurrency PoC in Python

#66

Post by dahauns »

tempay wrote: post #52
cocktailpeanuts wrote: post #39

Earlier quoted context omitted.

I'm pretty sure you have way more control over "presentation" when you use HTML vs PDF.

No you don't, HTML has massive variation between devices and what software is used to display it. Try setting your screen resolution to 640x480 and opening a webpage or, even worse, modifying DPI. PDFs on the other hand specify exactly where to place each glyph (admittedly there is still variation between software but it's much more consistent).

You sure do - the variation between devices is the manifestation of the ability to control layout depending on the recipient's display's resolution and size.

If anything, a PDF designed for A4/letter is going to be cumbersome to read on a (probably rather small) 640x480 display.

The sad state of PDF rendering on (most) e-book readers should be evidence enough.

Re: Show HN: Very basic blockchain-free cryptocurrency PoC in Python

#67

Post by literallycancer »

cocktailpeanuts wrote: post #39
literallycancer wrote: post #34

Earlier quoted context omitted.

Try reading the HTML version of Fielding's paper and tell me it looks better than the pdf. It might have been invented for that purpose, but that doesn't mean it's still suitable for it. When you are writing a paper, you want to control the presentation, not just the content.

I'm pretty sure you have way more control over "presentation" when you use HTML vs PDF.

More control over how it looks at the users' end with HTML than I do with Latex? Yeah, I don't think so. Why would everyone be using JS if you could do whatever you needed in HTML?

Re: Show HN: Very basic blockchain-free cryptocurrency PoC in Python

#68

Post by immad »

JauntyHatAngle wrote: post #58
immad wrote: post #57

Earlier quoted context omitted.

Number of new Bitcoins a day: 2063 [1] Transaction fees in Bitcoin: 272 [2] So transaction fees are not insignificant. 1: https://blockchain.info/charts/total-bitcoins July 6th data 2: https://blockchain.info/charts/transaction-fees July 6th data

That's total, not per block. Per block, fees average 0.9btc iirc. Transaction reward is 12.5 btc 0.9 is not insignificant, but compared with block reward, the true (current) incentive providing block security is not in question, and that is what was being discussed.

Per block or per day is the same thing. Also better to look at it on a day level since transactions+fees vary throughout the day

Re: Show HN: Very basic blockchain-free cryptocurrency PoC in Python

#69

Post by jcfrei »

flashdance wrote: post #64
jcfrei wrote: post #48

Earlier quoted context omitted.

> There is no mechanism to link cost of proof of work generated to the value being transacted. With a blockchain, scarcity of space per block leads to a fee market forming, and fees paid increasing as the value contained per transaction increases. This leads to security (proof of work) increasing in proportion to value that needs to be protected. My understanding of proof of work is that it's used to limit the number…

> If block creation intervals were lower it would compromise the security of the system and enable attacks with much less than 50% of the hash power. Not really. The odds of an attacker successfully generating a double-spending block remain the same with a lower block interval. Many alternative cryptocurrencies have far shorter blocktimes: Litecoin has 2.5min blocktimes, and ethereum is less than 30 seconds IIRC, and…

> Not really. The odds of an attacker successfully generating a double-spending block remain the same with a lower block interval. Many alternative cryptocurrencies have far shorter blocktimes: Litecoin has 2.5min blocktimes, and ethereum is less than 30 seconds IIRC, and they don't have problems with rampant double spends.

I based my statement on the following paper: Serialization of Proof-of-work Events: Confirming Transactions via Recursive Elections: https://eprint.iacr.org/2016/1159.pdf

Unfortunately, recent research has shown that the Nakamoto consensus has severe scalability limitations [6], [25], [11], [18]. Increasing the system’s throughput (either via an increase in block size or block creation rate) comes at the expense of security: Under high throughput, Nakamoto’s original guarantee no longer holds, and attackers with less than 50% of the computational power are able to disrupt the system. To avoid this, Bitcoin was set to operate at extremely low rates. The protocol enforces a slow block creation rate, and small block sizes, extending the blockchain only once every 10 minutes (in expectation) with a block containing up to 1 MB (roughly 2,000 transactions). Users must thus wait a long while to receive approval for their transfers.

Regarding litecoin: litecoin does have a lower block creation time of 2.5 minutes - however if you look at the average block size of litecoin it averages around 15kB, compared to ~950 kB of bitcoin (basically exhausting its 1MB limit): https://bitinfocharts.com/comparison/size-btc-ltc.html Considering the litecoin network operates way below its maximum capacity a double spending attack is indeed unlikely. However whether that security would hold up under full load remains to be seen.

Re: Show HN: Very basic blockchain-free cryptocurrency PoC in Python

#70

Post by flashdance »

jcfrei wrote: post #69
flashdance wrote: post #64

Earlier quoted context omitted.

> If block creation intervals were lower it would compromise the security of the system and enable attacks with much less than 50% of the hash power. Not really. The odds of an attacker successfully generating a double-spending block remain the same with a lower block interval. Many alternative cryptocurrencies have far shorter blocktimes: Litecoin has 2.5min blocktimes, and ethereum is less than 30 seconds IIRC, and…

> Not really. The odds of an attacker successfully generating a double-spending block remain the same with a lower block interval. Many alternative cryptocurrencies have far shorter blocktimes: Litecoin has 2.5min blocktimes, and ethereum is less than 30 seconds IIRC, and they don't have problems with rampant double spends. I based my statement on the following paper: Serialization of Proof-of-work Events: Confirming…

Oh, I see what you mean now! The block propagation delay that larger/faster blocks would cause could allow attackers to double spend with less than 50% of the network because the blocks of honest miners will be occasionally orphaned while your secret chain won't. The longer the delay... the more orphans, and the bigger advantage you have. Is that the effect that you are describing?

If you're interested in how big the delay is you can check this out, it's cited to the paper you linked me and I found it helpful.

http://ieeexplore.ieee.org/xpls/icp.jsp?arnumber=6688704

Post reply on HN