Blockstream hired Rusty Russell to work on a lightning network implementation. This is going to be big. Now it appears that the development efforts for sidechains and lightning networks are coming together. Russel, who joined Blockstream a few weeks ago, is working on lightning networks, and one of his first actions was to set up a Blockstream-hosted mailing list for “Discussion of the development of the Lightning Network, a caching layer for bitcoin.” The new mailing list archives are freely accessible.
“They hired me,” Russel said on Reddit. “We agreed I’d be working on developing lightning. I set up a mailing list and am developing a toy prototype to explore the ideas. Will put on github once that’s ready (two weeks?) but it’s a long long way from anything someone could use. I’m excited about lightning, but it’s a marathon, not a sprint.” |
|
|
|
sorry to disappoint everyone but i've always said:
"The geeks fail to understand that which they hath created".
so since Gavin define himself as an "all-around geek", what's your way forward? (by the way Peter Todd and Gavin will be on the next LetsTalkBitcoin episode, along with Adam/Andreas/Stephanie to talk about bitcoin scalability.) |
|
|
|
- other things we don't know yet caused by rising block max size. (Mircea will deploy his 'GavinCoin Short' financial weapon of mass destruction, with utterly unpredictable consequences)
Expanded that for you. Thanks for your time. In the last point I was referring to problems related to unexpected technical issues and/or unforseen demages to the economic incentives structure, rather than political maneuvers. |
|
|
|
The reason we have to worry about miners producing "too large" blocks is because they don't pay for all the P2P network resources they use (neither do end users).
All the arguments we have about resource consumption are derived from that primary design flaw.
If we fix it, then we won't have to argue any more.
Well put. Till we have had a 1:1 ratio between full node and miner, the block reward did pay for all the resoures involed in the process. Once such ratio started to decrease, due to the introduction of mining pools, mining and full node role became more and more decoupled. The block reward remains on the miner side, though. |
|
|
|
there is another radical view from Justus, see here:
remove the block max size limit completely (b/c it's an artificial scarcity), while at the same time introduce a
price discovery mechanism into full nodes p2p network to determine nodes services prices (e.g. validation, txs relay, ect etc)
I may be wrong on details, but this is afaik already used in Monero. And sounds like a good plan. It's a bit different I think, quoting myself here so the experts can make a judgement. I'm far from been an expert, but AFAIU Justus's proposing to remove completely the max block size limit. His reasoning is based on the fact that block space is a naturally scarce resource and that it should be better "regulated" by the free market rather than by a "central" authority through the application of production quota. With "block space price" he meant the cost of adding a tx to a block, that will be computed taking into account all the needed resources to complete such a task, so: bandwith, storage, etc. etc. involved in being a relay node, a miner (not hasher) or a full node, you name it. He then continues arguing that at the moment the bitcoin p2p network lacks of the necessary price discovery mechanism for such a scarce resource. To solve the problem this is his proposed solution:
... we need a mechanism via which the nodes can pay each other.
This mechanism exists in Bitcoin now, and it’s called micropayment channels.
Any two nodes can connect and they have this mechanism via which, if they can
agree on who owes what to whom, they can construct a payment and they can
adjust that payment as rapidly as they need to and settle it infrequently on the
Bitcoin block chain. This free competition in an open market introduced by this will avoid the aforementioned centralization problem. ps Justus, sorry for any misinterpretations. |
|
|
|
Sorry to pose a stupid question: what are the reasons why the limit cannot be raised?
main reasons that opponents to the increase state are: - centralization - fees discovery price distortion - UTXOs size will increase significantly - Tor could not be used anymore - other things we don't know yet caused by rising block max size. All valid reason to keep developing and not accept the 20MB block proposal as a final solution. To attempt solving those problems buy limiting block size is an expression of a lack of creativity the one i keep hearing getting complained about more so now is the one Ice brought up earlier; UTXO. i don't get that one. the UTXO is stored on disk and has a 100MB cache stored in RAM that limits filling it up. yes, the UTXO set is increasing apparently according to Statoshi, but if it only takes up 100MB, what's the big deal? |
|
|
|
Sorry to pose a stupid question: what are the reasons why the limit cannot be raised?
main reasons that opponents to the increase state are: - centralization - fees discovery price distortion - UTXOs size will increase significantly - Tor could not be used anymore - other things we don't know yet caused by rising block max size. All valid reason to keep developing and not accept the 20MB block proposal as a final solution. To attempt solving those problems buy limiting block size is an expression of a lack of creativity I see Gavin proposal as a stimulus to get a proper debate. And infact this proposal got it started. And imo we're somewaht moving towards a compromise. See last gavin email on btc dev mailing list: http://sourceforge.net/p/bitcoin/mailman/message/34094753/ |
|
|
|
Sorry to pose a stupid question: what are the reasons why the limit cannot be raised?
main reasons that opponents to the increase state are: - centralization - fees discovery price distortion - UTXOs size will increase significantly - Tor could not be used anymore - other things we don't know yet caused by rising block max size. Thanks. Oh ok. I think satoshi indicated that it should be raised, and it's also quite obvious that BTC will not make it to anything more widely used than it is now if it's not raised. Without offchain and centralization. Are there other arguments from the pro-raisers I have missed? there is another radical view from Justus, see here: http://bitcoinism.liberty.me/economic-fallacies-and-the-block-size-limit-part-1-scarcity/http://bitcoinism.liberty.me/economic-fallacies-and-the-block-size-limit-part-2-price-discovery/to make a long story short: remove the block max size limit completely (b/c it's an artificial scarcity), while at the same time introduce a price discovery mechanism into full nodes p2p network to determine nodes services prices (e.g. validation, txs relay, ect etc) |
|
|
|
Sorry to pose a stupid question: what are the reasons why the limit cannot be raised?
main reasons that opponents to the increase state are: - centralization - fees discovery price distortion - UTXOs size will increase significantly - Tor could not be used anymore - other things we don't know yet caused by rising block max size. |
|
|
|
last time I've checked Satoshi himself explicitly state that max block size limit was a temporary band aid to avoid a certain type DoS attack to the bitcoin network, just for the record.
For the record, I've never disputed the origin of the 1mb max block size, ... fair enough. I was just trying to keep separate our own speculation (as in "ideas or guesses about something that is not known") from Satoshi's actual statements, such as: It can be phased in, like:
if (blocknumber > 115000)
maxblocksize = largerlimit
It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don't have it are already obsolete.
When we're near the cutoff block number, I can put an alert to old versions to make sure they know they have to upgrade.
or Forgot to add the good part about micropayments. While I don't think Bitcoin is practical for smaller micropayments right now, it will eventually be as storage and bandwidth costs continue to fall. If Bitcoin catches on on a big scale, it may already be the case by that time. Another way they can become more practical is if I implement client-only mode and the number of network nodes consolidates into a smaller number of professional server farms. Whatever size micropayments you need will eventually be practical. I think in 5 or 10 years, the bandwidth and storage will seem trivial.
or, fwiw, : And there is this: The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime.
and last but not least The sooner you Monopolist Maximalists get over the fact that GavinCoin doesn't have the required 80% consensus, the better.
I won't define myself a "Monopolist Maximalists", you're misinterpreting my intentions. |
|
|
|
we would end up with an Austrian fork and a Keynesian fork dueling it out
(snip) Satoshi's Austrian fork can continue to represent a new store of value and settlement system, guaranteeing for the first time in history every human the opportunity to be their own bank. (snip) last time I've checked Satoshi himself explicitly states that max block size limit was a temporary band aid to avoid a certain type DoS attack to the bitcoin network, just for the record. |
|
|
|
What a pity, such offline keys exchange technique won't be open source 2. Will it be open source?
Probably not. The main reason for this is that most of the Elliptic Curve crypto functionality
used in the OtherCoin firmware is only available as a set of proprietary crypto functions by
the secure chip manufacturers (NXP and Infineon). We are bound by NDAs and contractual
terms with them to not expose any proprietary and confidential information and that covers
the crypto functionality inside the OtherCoin.
However, as noted above, the OtherCoin has no access to your keys, it does not sign
transactions or communicate to the outside world by itself in any way. Its only purposes are
to generate Bitcoin keys, keep them safe and certify that they haven’t been revealed or
securely send them to another card.
Closed source, non-auditable crypto it's not something I would trust enough to put any value into. |
|
|
|
Hi all, long time no see. I've just discovered I developed a sort of addiction to btctalk :-) I just found out an hidden "gem" in the development section: "Off-chain anonymous transactions by secure transfer of private keys" I think the apparent lack of interest is due to the fact that OtherCoin doesn't claim (or is expected to have) a net effect on the Bitcoin price. Its intention is to simply make off-chain truly private transactions possible. As a side effect, it would also make any blockchain transaction analysis useless (since coins could exchange hands offline hundreds or thousands of times without any trace in the blockchain or anywhere else on the Internet). It also removes the one to one mapping between addresses and persons - in the current system, once you've identified who owns a particular address, you can safely assume that any past or future payments sent to that address belong to that person. With OtherCoin in place, an address could effectively be "owned" by hundreds of people, just at different moments in time.
Here the link for the updated white paper: http://www.othercoin.com/OtherCoin.pdf |
|
|
|
Thanks for the links, appreciated. (Note to self: every once in a while have a look at r/bitcoin) |
|
|
|
this is actually inspiring that all these divergent opinions still have the maturity and willingness to break bread together in the same room. i'm sure all their differing views were aired and hopefully some positive consensus will arise:  Nick Szabo does actually exist, he's not a virtual entity as I used to believe  If I may, in which occasion those ladies and gentlemen gathered together ? |
|
|
|
If I recall correctly, the Bitcoin dev team was really excited about Zerocoin, until they saw that computational overhead which rightfully scared them away.
Now a zerocoin sidechain that is merged mined with Bitcoin and only lives off of it's own transaction fees, would enable people to fully clean any coin they have for a modest fee.
I vaguely remember the problem you mentioned and the shared secret needed in the bootstrapping step as the main causes why zerocoin wasn't merged, but I could be wrong. Now both of them are solved in zerocash, though a merge now is highly improbable for economical, political and technical reasons. |
|
|
|
Zerocoin is an example of a true innovation as I see it. Zerocoin does not rely on mixing as Monero does, but implements true removal of all history. This is something that neither Bitcoin nor Monero can do. If someone made this, I'd seriously consider it.
http://zerocash-project.orghttps://github.com/scipr-lab/libsnarkhttp://www.scipr-lab.org/How are Zerocash transactions checked for correctness?
For a mint transaction, the commitment cointained therein is constructed so that that anyone can verify that the committed coin has the claimed value.
For a pour transaction, anyone can verify that the zero-knowledge proof contained therein is valid (and that a few other simple invariants hold). For efficiency, however, Zerocash does not use "any" zero-knowledge proof, but leverages zero-knowledge Succinct Non-interactive ARguments of Knowledge (zk-SNARK) systems, which are zero-knowledge proofs that are particularly short and easy to verify. Specifically, Zerocash uses zk-SNARKs constructed by SCIPR Lab described in BCTV13; such proofs are less than 300 bytes long and can be verified in only a few mmilliseconds.
|
|
|
|
|
Show Posts
