Bitcoin Forum
September 28, 2016, 06:47:42 PM *
News: Latest stable version of Bitcoin Core: 0.13.0 (New!) [Torrent]. Make sure you verify it.
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 ... 228 »
1  Bitcoin / Development & Technical Discussion / Re: implicit cost of pegged sidechains on: September 26, 2016, 01:45:17 AM
I disagree with the assertion that "the only source of value difference between coins in the two networks is the friction related to the technical operation of the peg".
One could make the argument that another important source of value difference is the degree to which people are willing to hold either currency.
They aren't separate currencies. If you have 100 BTC in a sidechain and would prefer to have BTC in the parent chain, you simply move it. No third party or exchange is involved, only the fees and delays associated with making a transaction.

Quote
If I created a peg while the Ethereum price was high, pegging BTC to Ethereum at the pre-DAO rate,
This doesn't make any sense at all: you cannot 2wp ethereum to BTC: they are separate currencies; with their own issuance and supply. Trade between them requires counterparties and cannot be guaranteed to be available at any particular exchange rate.
2  Bitcoin / Hardware / MOVED: [Guide] Dogie's Comprehensive Manufacturer Trustworthiness Guide [1st Feb 2016] on: September 24, 2016, 10:35:35 PM
This topic has been moved to Investigations.

https://bitcointalk.org/index.php?topic=456691.0
3  Bitcoin / Development & Technical Discussion / Re: implicit cost of pegged sidechains on: September 24, 2016, 10:27:10 PM
The exchange rate is fixed because _every_ sidechain coin is backed by a fixed amount of coin in the parent chain with a fixed, programmed, and mechanically fulfilled guaranteed delivery.

This is unlike foreign currency, but like USD in your pocket vs USD in paypal (but without the custodial risk). Anyone with a coin in either can effectively move their coin into the other at any time using the peg mechanism. With a foreign currency there are separate independent supplies of the currency and no guaranteed exchange.

The only source of value difference between coins in the two networks is the friction related to the technical operation of the peg (the time preference and transfer costs, relative to the differential demand).
4  Bitcoin / Development & Technical Discussion / Re: Bitcoin profiling results on: September 07, 2016, 06:29:47 PM
You have txindex enabled-- that severely harms performance, there are just so many transactions in the history that the performance isn't great.

Without txindex, and the dbcache turned up enough-- it will manage to complete a full sync without doing any writes other than the block/undo files.

The reason you see writes at start is leveldb will recompact its logs at start, so that is expected.

No doubt there is potential for improvement here, but the level of write amplification you see isn't unexpected. Bitcoin transactions are effectively a highly compressed format. There is a lot of work involved in synchronization.
5  Bitcoin / Development & Technical Discussion / Re: Why do you need to download 7 years of chain block on: September 05, 2016, 12:53:43 AM
Dear Greg, it seems you've missed a part of the protocol. Let me provide a quick description of Rollerchain, more precisely, modifications from the Bitcoin.

1. We authenticate the state and include root value into a blockheader. It is an old idea yes, and already implemented in Ethereum (and some other coins) as mentioned in the paper.

2. We then modify a Proof-of-Work function. A miner chooses "k" state snapshot versions out of last "n" a (sufficiently large) network stores collectively. In order to generate a block miner needs to provide proofs of possession for the state snapshots. On a new block arrival a miner updates k+1 states, not one, so full blocks (since minimal value in "k") are also needed.

Thus miners store a distributed database of last "n" full blocks AND state snapshots getting rewards for that activity. A new node could download not just a last snapshot, but from "n" blocks ago (or from somewhere in between). So it is not needed to "strongly trust the hashpower", but "hashpower" and also up to "n" last full blocks("n" considered to be >> than a deepest fork possible, say, 5000-10000 for Bitcoin) . And this is not about SPV, but about getting fullnode-going-from-genesis security(with probability of divergence going down exponentially with "n", see Theorem 2). Full blocks not needed in order to mine could be removed by all the nodes.

If you have concerns about this scheme please let me know, and I will try to formalize/address them.

Authenticated state root in a block header could be useful anyway for better SPVs. On efficient implementation, we're now working on that along with benchmarking. Let's see how it goes.


P.S. However, as PoW function modification is needed it is unlikely Bitcoin can go this way(miners will not throw away their ASICs).

I did not miss this.   But unless I am misunderstanding you,  you appear to be conflating two orthogonal changes.

One is the change to the POW which requires the miner to show possession of state snapshot data.  This does nothing to assure users that the data is correct.  It ~may~ increase the odds there are multiple copies of it (though unless I misunderstand it-- your design is trivially delegatable so long as the miners are willing to trust the party storing the data until their coins mature, which users of mining pools already do almost ubiquitously).

The other is that you begin nodes from a state snapshot, not at the tip, but at some point somewhat back. This is also taught in in the citations I provided above.  This also does not prove that the state is correct, in fact it provides no evidence at all that the state is correct except under a strong assumption.

Instead, participants hope that the state is correct without checking under a strong assumption that the majority hashpower would not extend a chain with invalid state updates. This is the SPV security assumption.

It is different and weaker than the normal Bitcoin behavior, trusting a majority hashpower for the soundness of state updates and not merely their sequencing. In practice it is not sufficient to simply take such a strong assumption and not question it's validity-- normally the SPV hashpower assumption is justified by the widespread and economically significant use of full nodes which will not be deceived by dishonest miners; but with full nodes also making a SPV assumption for blocks away from the tip, this argument becomes circular.

The SPV assumption is especially concerning because we have discovered that miners have begun bypassing validation themselves in order to mitigate the negative effects of larger amounts of transaction data on propagation. State sampling proof of work has been argued as a potential improvement for this particular issue, but proposals so far have worsened the generation of progress in the mining function (as the last miner to create a block has a state update advantage) and they still leave plenty of opportunity to optimize by shortcutting the parts of validation that the state updates do not expose.


Perhaps it would be revealing to answer a question:  You are a new node joining the network. I am part of an attacking consortium which has, for several months, had a super majority hashpower at my disposal.  Can I cause you to accept a chain extending the chain from no further than a few months back, otherwise compatible with a 'honest chain' (if it existed)-- meaning containing all the same transactions and ownership except as mentioned-- where I instead have a million extra BTC reassigned from the earliest blocks?
6  Alternate cryptocurrencies / Altcoin Discussion / Re: /src/checkpoints.cpp:376 HELP on: August 26, 2016, 01:17:35 AM
Centralized fake cryptocurrency is centralized fake cryptocurrency... and belongs in the altcoin section.
7  Bitcoin / Development & Technical Discussion / Re: Why do you need to download 7 years of chain block on: August 26, 2016, 12:24:16 AM
In the first place, there is no rationale to store 7 years of history for synced nodes. But how a new node could get into network if all the fullnodes have thrown away all the blocks(except last few ones to handle possible rollbacks)? Bitcoin has no answer for that.

I've developed a proposal to fix the issue and solve some important questions towards better scalability. The paper is just uploaded http://arxiv.org/abs/1603.07926 . I would be happy to get feedback.

This paper is a bit of a disappointment, sad to say.  First-- it makes a number of false claims about the capabilities of the existing Bitcoin system, e.g.

"To be rational it is needed to switch to an implementation of the Bitcoin protocol which does not hold the unnecessary data (such an implementation of a full node does not exist to the best of our knowledge)."

The whole reason that Bitcoin has state snapshots, as described in the paper, was because they were introduced to enable strong pruning (a more limited version is described in section 7 of the Bitcoin whitepaper).  Bitcoin has supported operating in a pruned fashion for _years_.


The primary suggestion the paper is making is to bootstrap nodes from state snapshots. The paper describes this as "trustless" but it is _not_, rather it makes the same strong assumption of hashpower honesty that SPV (lite wallet nodes do), implicitly trusting the history of the longest chain to be faithful.

This is not a new idea, its expression spans at least back to 2011:

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

and

https://en.bitcoin.it/wiki/User:DiThi/MTUT

(as is using random tests for data in the mining process,-- though the scheme you suggest is fully delegatable, so long as the miner doesn't mind giving temporary custody of his income to the centralized party holding the world's only copy of the blockchain. Smiley )

The state commitment proposals face a couple challenges, one is that if you are willing to strongly trust the hashpower-- then why not use the vastly more efficient SPV mode?  The other is that the initial efforts to implement continual state commitments found that the overhead (primarily IO) of maintaining them multiplied the full node operating costs at runtime by several fold.  The costs have made what would otherwise be another option for client security less attractive, supporting a more niche security model would be fine if it were inexpensive.

Alternative designs like mimblewimble try to make bootstrapping more efficient without adding a new form of strong trust towards miners.
8  Bitcoin / Development & Technical Discussion / Re: Bitcoin profiling results on: August 23, 2016, 12:53:16 AM
Why isn't that done yet?  Because until very recently it was burred in the profiles; optimization elsewhere has exposed it.

Any such change has to be done with great care because of consensus consistency of course--

and optimized hash functions for non-parallel use are not ~THAT~ much faster:

SHA256_avx,255,0.0039705,0.0040791,0.00397483
SHA256_basic,175,0.00599706,0.00610304,0.00599851
SHA256_rorx,319,0.00334549,0.00345182,0.00334802
SHA256_rorx_x8ms,319,0.00328481,0.00339317,0.00328667
SHA256_sse4,255,0.00395852,0.00404716,0.00396052

basic is the plain code we have today, the fastest in that test (rorx_x8ms) is only 1.825x faster.

https://github.com/laanwj/bitcoin/tree/2016_05_sha256_accel

I expect this to go into 0.14 sometime relatively soon.

Use of a 4-way implementation would speed it up further, but making good use of 4-way sha2 is technically somewhat difficult-- not just a drop in change, and there are only a few places where it can really be used at all.

Wladimir has done similar testing for the CRC32c, https://github.com/laanwj/bitcoin/commit/431c1b987b34589f32f4c2d0ee0f2571ba70e349

in all cases, these higher performance versions require use of special instruction sets that aren't available on all systems so additional code is needed for runtime autodetection. Not a big deal, but part of the reason that it wasn't magically changed the moment it was the highest point in the profile.

9  Bitcoin / Development & Technical Discussion / Re: Turing completeness and state for smart contract on: August 20, 2016, 01:03:41 AM
The gist of an earlier comment of yours seemed to be: "writing smart contracts is inherently hard and unnatural, so it's fine if the scripting language is hard to understand." I just don't see how one aspect of writing contracts being hard (getting the logic right) implies that it would be better for other aspects to be harder than they need to be.

If a declarative version of Bitcoin script made mistakes less likely, what is the downside? Are you worried about newbs who just learned a bit of javascript thinking they can write secure smart contracts just because Bitcoin script v2 might look a bit more like javascript? So the fact that current script looks intimidating is actually good? If so would it have been even better if Satoshi made all op codes of the form OP_XYZ where X, Y, and Z were digits? And maybe disallowed spaces when not including them would still be unambiguous? That would certainly reinforce in people's mind that writing Bitcoin script is tricky.

You misunderstood what I was saying.

A declarative model doesn't reflect the reality of these systems well. It is easier to get started, but hard to do things right, and very hard or impossible to to be confident that you got things right when you did.

A more functional model reflects the reality of the systems better, while also providing powerful scaling and analysis benefits.  I believe it is possible to construct systems which are harder to get started, but once you get something working its very likely to get things right, and hard but far from impossible to _prove_ you're achieving the properties that you set out to achieve.

I haven't proven that better can be done, yet (unless you count Bitcoin script)-- but what DAO/ETH seem to be proving is that at least that design is too dangerous to be used-- when their highest profile contract, reviewed by the designers of the system/language, got robbed blind by a rather simple vulnerability.
10  Bitcoin / Development & Technical Discussion / Re: Questions about hash_serialized, returned by gettxoutsetinfo on: August 17, 2016, 09:15:46 AM
The only purpose of it is bitcoin core specific software testing, it's effectively free to compute while returning those other statistics, and it allows rapid isolation of suspected database corruption or inconsistency.

The structure of the hashing is not well suited to other applications.

and xor all the hashes together to get the final value.
Congrats, you win today's failed cryptography trophy. Smiley That kind of structure is trivially to second preimage attacks using wagners algorithm for solutions to the subset sum problem.  Order independent accumulators are a tricky subject, the only that I'm aware of that have any real argument for security have huge hashes and are very slow.

The data hashed here is also _highly_ implementation specific and subject to change in any new version without warning.
11  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANNOUNCE] Ixcoin - a new Bitcoin fork on: August 17, 2016, 02:11:12 AM
Your project contains the old centralized "alert" system previously copied from upstream Bitcoin. This system lets the holders of a private key send messages to be displayed in the error field. Because of its limited utility, potential for abuse, known disclosure of the key to at least one untrustworthy party (and is believed to be compromised), and frequent use to justify other centralizing features this system has long been deactivated (and now is completely removed) upstream.

I would recommend you remove this system by adopting this code from upstream: https://github.com/bitcoin/bitcoin/pull/7692 or the parallel PR in bitcoin xt, https://github.com/bitcoinxt/bitcoinxt/pull/150
12  Bitcoin / Development & Technical Discussion / Re: Using the confidential transaction sum for proof of reserves on: August 11, 2016, 10:18:21 AM
CT for solvency proofs is well known, I posted about it here (someplace) on the liabilities side some time ago.

Whats even more interesting is that private assets side is also possible in Bitcoin today:

http://crypto.stanford.edu/~dabo/pubs/abstracts/provisions.html

Unfortunately there is relatively little interest from most exchanges in these tools.
13  Bitcoin / Development & Technical Discussion / Re: why are people trying to hide their IP? on: August 10, 2016, 10:05:16 PM
There are several companies performing sybil attacks on the network.  They connect to every node they can reach (the 8 limit is for _outbound_ connections) and also listening to connections, running many fake nodes so that it is likely that you will connect to them. They also monitor the timing of addr messages to attempt to infer which addresses are connected to the nodes they are connected to.

By monitoring the timing of transaction announcements they can learn a lot about transaction origins, especially if addresses are reused.


As far as i understand, it's even a bad idear to use bitcoin and tor:
This is highly misleading. The claim is that attackers can DOS attack tor exits, causing a tor using Bitcoin user to potentially need to stop using Tor during a DOS attack.

This is untrue because normally with tor Bitcoin nodes are connecting to other bitcoin nodes as hidden services, no exit is involved... and not very relevant because, "maybe tor gets DOS attacked and you need to either wait or switch it off" is in no way worse than never using tor in the first place.
14  Alternate cryptocurrencies / Altcoin Discussion / Re: Is the blockchain's purpose being redefined by the forked Ethereum Community? on: August 04, 2016, 08:07:13 PM
It didn't start with them. It started with people pushing for a hardfork in Bitcoin making the factually unsupported claim that whatever "the most" hashpower says is what happens.

The fact that Bitcoin software has _never_ worked like that (nor any altcoin that I'm aware of) hasn't phased them. Ethereum has just been running what that misunderstanding. It'll be pretty interesting to see what happens when ETC ends up with more hashpower.
15  Economy / Games and rounds / Re: 1000 BTC GIVEAWAY! From your friend rekcahxfb on: August 03, 2016, 04:48:47 PM
Hey, rekcahxfb.

You should post a list of eligible addresses once your contest closes.

Then you should use a block that comes after to randomly and uniformly select the winner.

(For those who didn't notice, the coins here appear to be unrelated to bitfinex at least)
16  Bitcoin / Bitcoin Discussion / Re: Another closed door Core - Chinese miners meeting on: August 02, 2016, 06:08:53 PM
https://bitcoinmagazine.com/articles/bitcoin-miners-and-developers-meet-in-california-to-improve-communications-1470158657
17  Bitcoin / Bitcoin Discussion / Re: Another closed door Core - Chinese miners meeting on: August 02, 2016, 08:07:47 AM
They came out to meet with many parties in the area, in fact. You just hear about it in this case.  The meeting was mostly social-- discussing our common passion (Bitcoin) and trying to improve communication.   I think notes are going to be posted, in fact, because we're dweebs like that.

I thought it was really positive-- and good to meet up with people face to face that I'd only talked with in email before.

The Bitcoin industry seriously needs better communication-- especially crossing language and cultural barriers-- rather than hot comments on social media. Improved communication will lead to fewer potential avenues for miscommunication and better cooperation in the future.  Don't buy into rbtc fud. Smiley
18  Bitcoin / Bitcoin Discussion / How have fungiblity problems affected you in Bitcoin? on: July 29, 2016, 02:33:27 AM
Privacy and fungiblity are essential components for any money-like system.
Without them, your transactions leak information about your private
activities and leave you at risk of discriminatory treatment. Without them your security is reduced due to selective targeting and your commercial negotiations can be undermined.

They're important and were consideration's in Bitcoin's design since day one. But Bitcoin's initial approach to preserving privacy and fungiblity -- pseudonymous addresses-- is limited, and full exploitation of it requires less convenient usage patterns that have fallen out of favor.

There are many technologies people have been working on to improve fungiblity and privacy in different ways-- coinjoins[url=http://and [url=https://bitcointalk.org/index.php?topic=321228.0]swaps] and [url=https://bitcointalk.org/index.php?topic=321228.0]swaps, confidential
transactions
, encrypted/committed transactions, schnorr
multisignature, MAST, better wallet input selection logic, private wallet scanning, tools for address reuse avoidance, P2P encryption], ECDH-derived addresses, P2P surveillance resistance, to name a few.

Having some more in-the-field examples will help prioritize these efforts. So I'm asking here for more examples of where privacy and fungiblity loss have hurt Bitcoin users or just discouraged Bitcoin use-- and, if known, the specifics about how those situations came about.

Please feel free to provide links to other people's examples too, and also feel free to contact me privately ( gmaxwell@blockstream.com GPG: 0xAC859362B0413BFA ).

I also posted this question on Reddit, but though I might get a broader audience here.
19  Economy / Exchanges / Re: Coinbase now supports Etherium; Is this a threat to Bitcoin dominance on: July 25, 2016, 11:52:20 PM
Heavily pre-mined (80%-ish currently), endlessly inflationary, 'cryptocurrency' which doesn't even provide ledger immutability...

20  Bitcoin / Development & Technical Discussion / Re: Incentivizing Bitcoin Nodes on: July 25, 2016, 11:07:40 PM

"Nodes with open ports are able to upload blocks to new full nodes. In all other ways they are the same as nodes with closed ports."

The contributor of those two lines makes it sound as if this difference between the two is negligible, when it isn't.

In fact, that quoted text sounds like it's overstating the differences-- nodes without open ports still forward blocks too.  The difference is that they make outbound connections and so they can't connect to each other... and now that HS support is integrated, even that difference is diminishing.
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 ... 228 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!