|
161
|
Bitcoin / Bitcoin Discussion / Re: From 370,000 Full Bitcoin Nodes to 6,000: What happened?
|
on: June 19, 2015, 08:34:11 AM
|
|
AFAIK the way to measure the # of nodes has been changed along the way. The crawler is actually counting nodes accepting incoming connections on port 8333. Earlier version takes into account also all of them.
That said the increased burden in running a full node had definitely contributed to the trend.
Unfortunately we don't know how much effect the increase size of the blocksize has had, due to the change in the way we observed the nodes number.
|
|
|
|
|
162
|
Economy / Speculation / Re: Gold collapsing. Bitcoin UP.
|
on: June 16, 2015, 03:00:31 PM
|
http://www.8btc.com/blocksize-increase-2Courtesy of google translator: Beijing June 11, 2015, five Chinese mine pool jointly organized the "mine pool Technology Seminar" at the National Convention Center participating F2pool.com, BW.com, BTCChina, Huobi.com, Antpool.com five mine pool cell technology for ore-depth discussions and reached consensus on the expansion part of the block. They agreed that capacity is needed Bitcoin block size; in ensuring the premise of unified Bitcoin network intends in the next period of time to accept the size does not exceed 8MB (8,000,000Bytes) blocks.
edit: just found out there's already a thread in the speculation section https://bitcointalk.org/index.php?topic=1091170.0
|
|
|
|
|
163
|
Economy / Speculation / Re: Gold collapsing. Bitcoin UP.
|
on: June 15, 2015, 10:08:08 PM
|
Remember this quote by Adam when the time comes that they make their proposal to change the Bitcoin protocol to enable LN and SCs. As you can probably tell I think a unilateral fork without wide-scale consensus from the technical and business communities is a deeply inadvisable.
The bar to add LN and SC enabling protocol changes is wide-scale consensus. If a small number of participants disagree, it doesn't happen by their own logic. Additionally these protocol changes significantly change what Bitcoin fundamentally is much more than a simple 20MB blocksize c This is the exact reason why I linked Adam's reply: quote for posterity the evaluation criteria used by opponents to gavin's block size increase proposal. That said, if memory serves the new opcode needed by sc could be introduced by a soft-fork. Though I have to agree that merged mined side chains would introduce a significant modification of miners economic incentives. One last thing, I think that at least Adam is not opposed to the increase per se, in fact he did say that LN and SC need a modification in the way max block size limit is handled (he talks about burst period), he even praise jgarzik bip 100 on the basis of the "slow" variation entangled in the proposal. edit: fix typo |
|
|
|
|
165
|
Bitcoin / Development & Technical Discussion / Re: Confidential Transactions, Content privacy for Bitcoin transactions
|
on: June 15, 2015, 04:34:03 PM
|
No matter how good this gets, the split over block size has caused a rift in BTC users and developers alike, some will be against this just as others fought the raise in block size.
I won't be so sure. Just to make an example: Justus Ranvier want to completely remove the max size cap, but at the same time really he does want confidential transaction integrated into the bitcoin protocol (check his btctalk post history to get a proof). I think that btc devs are infelligent enough to evaluate properly and objectively new ideas. That said, everything could happen. |
|
|
|
|
166
|
Economy / Speculation / Re: Gold collapsing. Bitcoin UP.
|
on: June 12, 2015, 04:37:16 PM
|
https://twitter.com/jgarzik/status/609371913748529153Making Decentralized Economic Policy BIP 100 Theory and Discussion, v0.3 draft Jeff Garzik < jgarzik@gmail.com> a.k.a. Another proposal to scale up bitcoin removing the max block size limit Protocol changes proposed: Hard fork to remove 1MB block size limit. Simultaneously, add a new soft fork limit of 2MB. Schedule the hard fork on testnet for September 1, 2015. Schedule the hard fork on bitcoin main chain for December 11, 2015. Default miner block size becomes 1MB (easily changeable by miner at any time, as today). Changing the 2MB limit is accomplished in a manner similar to BIP 34, a oneway lockin upgrade with a 12,000 block (3 month) threshold.
|
|
|
|
|
169
|
Economy / Speculation / Re: Kraken just introduced "Dark Pool"
|
on: June 11, 2015, 12:03:27 PM
|
Why is it a "pool"? Shouldn't it be a "Dark Exchange"?
The Kraken dark pool is an order book not visible to the rest of the market. Each trader only knows
their own orders. Traders can anonymously place large buy or sell orders without revealing their interest
to other traders. Typically, outsized orders, when seen by other traders will cause the market to move
unfavorably, making it more difficult to fill the order at the desired price. This unfavorable price movement
may be avoided in a dark pool.[/b]
|
|
|
|
|
170
|
Economy / Speculation / Kraken just introduced "Dark Pool"
|
on: June 11, 2015, 11:49:25 AM
|
We are pleased to announce the Kraken dark pool, a new feature that allows clients to discreetly
place large bitcoin orders and execute against similar sized orders at potentially better prices.
Kraken is now one of the few exchanges offering a dark pool for bitcoin.
The Kraken dark pool is an order book not visible to the rest of the market. Each trader only knows
their own orders. Traders can anonymously place large buy or sell orders without revealing their interest
to other traders. Typically, outsized orders, when seen by other traders will cause the market to move
unfavorably, making it more difficult to fill the order at the desired price. This unfavorable price movement
may be avoided in a dark pool.
Kraken will charge an extra 0.1% for dark orders. Dark pool trading is available to all Kraken clients
with accounts verified to Tier 2 or higher (for information on the account tiers click here). The minimum
dark order size is 50 Bitcoins and only limit orders are supported. The dark pool will accept orders
for trading between Bitcoins and EUR, USD, JPY or GBP. Dark pool pairings are designated by a “.d”
extension (e.g. XBT/EUR.d or XBT/USD.d).
|
|
|
|
|
171
|
Bitcoin / Bitcoin Discussion / Re: Epicenter Bitcoin interview - Mike Hearn
|
on: June 10, 2015, 12:22:47 PM
|
This is what I've posted on Reddit: I have a couple of questions after listening to this episode. Mike was saying that we don't know what will happen when the backlog will keep growing.
Why don't we have some sort of "Staging" blockchain where we can test stuff happening? Why don't we have a live laboratory for these kind of tests? Are we only using math to predict stuff? ELI5!
sidechain anyone ?  So you are telling me that since 2008 we didn't have any testing environment and that we had to wait for a new environment that is currently in alpha mode to be able to test stuff? Is this real life? Because I simply can't believe it! Why don't we have a testing environment? It appears that nobody can answer this and this is surprising me. I am panicked right now! easy, I was smiling. I mentioned SideChains in this context, because testing dangerous new features it is precisely what Adam Back envisioned SC for, among other things. That said, bitcoin has a test network, bitcoin core has a currently used test suite and Gavin hacked bitcoin core to deal with 20MB blocks and tested it using the real blockchain txs, you can look at http://gavintech.blogspot.it/2015/01/twenty-megabytes-testing-results.htmlSurely this is not enough, though. |
|
|
|
|
172
|
Bitcoin / Bitcoin Discussion / Re: Epicenter Bitcoin interview - Mike Hearn
|
on: June 10, 2015, 10:46:36 AM
|
This is what I've posted on Reddit: I have a couple of questions after listening to this episode. Mike was saying that we don't know what will happen when the backlog will keep growing.
Why don't we have some sort of "Staging" blockchain where we can test stuff happening? Why don't we have a live laboratory for these kind of tests? Are we only using math to predict stuff? ELI5!
sidechain anyone ? |
|
|
|
|
173
|
Economy / Speculation / Re: Gold collapsing. Bitcoin UP.
|
on: June 09, 2015, 08:08:30 PM
|
Some of those new opcodes look great.
When will they make it into Bitcoin?
maybe never. depends on how they perform on the SC. they already are in Core but have been disabled. from a cursory look there are only 2 novel proposed opcodes, namely: - A new DETERMINISTICRANDOM operation which produces a random number within a range from a seed.
- A new CHECKSIGFROMSTACK operation which verifies a signature against a message on the stack, rather than the spending transaction itself.
all the rest are OPCODEs that were disabled in 2010 due to security concerns. I mean the blinded amounts.
That's exactly the kind of improvement that should be added to the protocol.
what you're referring to with blinded amount? signature http://elementsproject.org/#signature-covers-valueedit: or "confidential transaction" ( http://elementsproject.org/#confidential-transactions) ? |
|
|
|
|
175
|
Economy / Speculation / Re: Gold collapsing. Bitcoin UP.
|
on: June 06, 2015, 01:19:55 PM
|
* edit you should say exchanges miners are not as powerful as you fear. I think they are overestimating there power. here is a quote from someone who once controlled almost 50% of the Bitcoin hash rate. As for China I think they are net sellers, and they want to offshore profit, i suspect a lot of volume is also hot air, look at the number of nodes in China and you get a feel for how well Bitcoin has penetrated there. If the whole of Chinese didn't fork (all 91 nodes) I think it would have little impact. A common misunderstanding: Miners actually have zero influence over hardforking. If a hard fork is going to happen, it doesn't matter if 99% of miners decide not to follow it. If all of the major Bitcoin businesses, payment processors, and exchanges move to Bitcoin (New) and the miners all stay on Bitcoin (Old), it doesn't matter, forks do NOT require mining consensus unless the fork requires one, such as the "Block Version 1" -> "Block Version 2" fork, where the network switched to enforcing version 2 blocks after 95% of the last 1000(?) blocks were V2. Bitcoin Fork A (95% of miners, 5% of businesses)
/
Prefork Bitcoin -----
\
Bitcoin Fork B (5% of miners, 95% of businesses)
Guess which one is going to retain any value? Especially post-fork when the miners realize they can't exchange their BTC for goods or cash because no exchanges will accept BTC-A coins. I believe we absolutely need to remove the 1MB block limit. I'm not opposed to the jump from 1MB to 20MB, as I think it will have very minimal impact what the new limit is for quite some time. I'm not sure if this jump to 20MB also implements the original proposal for automatically increasing the limit annually. I do have objections to that one as I think Gavin's original proposed annual increase was FAR too aggressive and optimistic regarding throughput and bandwidth quotas for huge portions of the world. What I think probably won't matter much though. With a March 2016 prospective date, I'm not so sure the pool will even still be around by the time it's time to choose a side, given how much noise is being made by regulatory bodies who have absolutely no clue what to do with Bitcoin but sure as hell want to regulate it anyways. This beg the question: does the 20MB hardfork require increasing the block version? |
|
|
|
|
177
|
Economy / Speculation / Re: Gold collapsing. Bitcoin UP.
|
on: June 02, 2015, 01:25:03 PM
|
We have no guarantee that Bitcoin Core is self-consistent (like it wasn't in March 2013). Due to the way that code was written, it's likely that we never will have such a guarantee.
If memory serves 2013 hardfork was more a "dependency" bug imho. Client with ver <= 0.8.0 cant's store block bigger than 512KB due to a Berkeley db default misconfiguration. It could have happened with any other external tool used by the client. That said I fully agree that we need to decouple the protocol definition from bitcoin core. In that regard what do you think about the plan to isolate the consensus code in a separete library? |
|
|
|
|
178
|
Economy / Speculation / Re: Gold collapsing. Bitcoin UP.
|
on: June 02, 2015, 08:46:55 AM
|
Sorry need to quote the first one explicitly: All rules I found are enforced. I am eager to learn any outstanding.
The biggest deliverable is serious testing.
I would love to get this production ready this year, but since I only work on this on my spare time and my family has other plans with me around Christmas, I can not commit.
Okay. You're missing at least one important rule, but I don't know what else is missing that I missed in review. Unless you object, I'm contemplating keeping this missing rule to myself for now so that it can function as a test of the testing. E.g. if the test don't find it, they're incomplete. Obviously I don't want to withhold information which could undermine the network, but absent better testing the software shouldn't be in production use anyways... and there are scarcely few good ways of testing the tests. Does this sound reasonable to you? My english vocabulary is not wide enough to define how presumptuous gmaxwell's reply was. Thanks for the pointer Adrian, very informative. |
|
|
|
|
179
|
Economy / Speculation / Re: Gold collapsing. Bitcoin UP.
|
on: May 31, 2015, 11:40:58 AM
|
Gavin's plan to break stagnation seems to have worked. Gregory Maxwell has proposed a blocksize increase plan (in a manner of speaking).
Any pointer to such proposal? |
|
|
|
|
180
|
Economy / Speculation / Re: Gold collapsing. Bitcoin UP.
|
on: May 29, 2015, 08:35:19 PM
|
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.” Explain to me why requiring centralized lightning nodes to be up 24/7 is a good thing? To buy your coffee? /sarcasm I though that increasing on-chain bitcoin network capacity is necessary (even for a lightning network implementation 3tps avg isn't enough(*)), that said I believe that a mainly-offline-sync-once-in-while solution to increase system capacity even more is desirable. This solution would be the result of a trade-off between different aspects: centralization, capacity, privacy, etc. etc. As I already said I won't use LN to buy a house, but I will definitely use it for my daily expenses. Sure If we were able to find some kind of mechanism that would not require a softfork, it would be amazing. Unfortunately, as sidechains also LN need a new opcode (and a solution to tx malleability) to be properly implemented. (*) on this podcast: https://letstalkbitcoin.com/blog/post/epicenter-bitcoin-joseph-poon-and-tadge-dryja-scalability-and-the-lightning-network Joseph Poon & Tadge Dryja, authors of the LN white paper, explicitly state that a max block size has to be increased to implement what they envision. |
|
|
|
|
Show Posts
