Bitcoin Forum
May 06, 2016, 01:08:48 PM *
News: New! Latest stable version of Bitcoin Core: 0.12.1 [Torrent]
 
  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 ... 223 »
1  Bitcoin / Bitcoin Discussion / Re: ToominCoin aka "Bitcoin_Classic" #R3KT on: Today at 08:00:20 AM
A number of big classic promoters were also big Wright-fighters.

I find myself wondering which way the causal arrow goes? Did Wright, as part of his general deception, convince some of these folks that he created Bitcoin and then spun them up on blocksize because it was his own poorly informed view of the future... or did Wright see their block-size mania as a juicy cognitive vulnerability and exploit it to gain their trust? Maybe a bit of both in a mutually amplifying cycle?

In any case, a strong relationship there would do a lot to explain a number of rather perplexing things-- including the absolute, yet wildly unjustified, confidence in the XT and Classic's forks when they lacked so much, including a productive and experienced set of people supporting them. As extreme as that confidence was in public, what I've seen in  in private is magnitudes worse. "No worries, the Creator will come and save the day."

The constant leaking "satoshi's vision" from that camp might also be connected here.

I'm interested in getting further data points on exactly how this scam was spreading in the Bitcoin space. I have some dates and some people, but a lot I don't know.

But perhaps I'm just being hopeful, -- since if this is true, the worst of this drama may be finally over.
2  Bitcoin / Development & Technical Discussion / Re: Can two signatures be identical? on: May 05, 2016, 07:49:28 AM
Assuming we are talking about Bitcoin signatures and we are not using deterministic k.

My understanding is that signing the same message with the same private key will not yield the same signature because of the random factor k. The odds of two signatures being equal is negligible under these conditions. Could someone confirm or refute this?

Thanks,
--h
probability of one out of the group order exactly (roughly 1:2^256, or one bit less assuming that both signature were from low-S enforcing signers). The only way two them to be identical is to pick the same k.
3  Bitcoin / Development & Technical Discussion / Re: Aggregated Schnorr Signatures Are Not Provably Secure Without Key-Prefixing on: May 04, 2016, 07:20:18 AM
From briefly observing Bitcoin/secp256k1 code of Schnorr sigs implementation, I've came to the conclusion it is assumed there multi-user Schnorr is about the same security as single-user. That was proven, but recently D. Bernstein did show the proof was incorrect, and multi-user Schnorr is provably secure only if key-prefixing. The paper is there: https://eprint.iacr.org/2015/996.pdf .

Please note absence of a provable security doesn't mean a practical attack exists. It could be found few years after though. Bitcoin devs please take care.
We're aware. (Though thank you, we could have not been as well).  In general I prefer prefixing-- without it the signature is not really a proof of knowledge--, and the libsecp256k1 "test schnorr" construction goes out of its way to enable things like compact signature key recovery while also using prefixing.
4  Bitcoin / Bitcoin Discussion / Re: The Wright Code (or not . . . maybe) on: May 04, 2016, 04:35:39 AM
There are rigid coding standards in core now, no one writes code there like they would on their own.

Left to my own devices, with no constraints I write code that looks like https://people.xiph.org/~greg/binomial_codec.c

...but you'd never see code that looked like that in Bitcoin Core.

It's quite easy to hide coding style in any case-- any senior developer has experience working in projects where they must adopt other people's preferred style.
5  Bitcoin / Bitcoin Discussion / Re: Satoshi Nakamoto aka Craig Wright Can't Spell Signature. Craig's Career is #REKT on: May 03, 2016, 06:16:21 PM
& vs &&  means that the commands are running in parallel in his script, instead of sequentially.

This creates a race condition where the input is decoded to a file after the next step has already read it.

The misspelling of signature in the script also makes his script read from the wrong file (whatever file is referenced by the misspelled environment variable).

Most remarkable is that these scripts were not Wright's creation: https://gist.github.com/ezimuel/3cb601853db6ebc4ee49  They were plagiarized from the web but modified to insert these bugs.

The net effect of these modified scripts is that the modifications would allow you to use them to fake a signature.
6  Bitcoin / Bitcoin Discussion / Re: Craig Wright Gavin Andresen = PLOT on: May 02, 2016, 11:40:18 PM
Arguably, he made a bad strategic decision to give up the lead developer role.  If he was still lead dev, he could decide core's priorities between big blocks and seg witness.
No he couldn't-- the comment betrays a misunderstanding of how Bitcoin and open source development works.  "Lead dev" is not a position of authority, and if he wanted to push in a direction the contributors didn't agree with, he'd find himself where he is now, regardless of what happened there...
7  Bitcoin / Development & Technical Discussion / Re: txs in blocks: why Merkle tree instead of regular hash? on: May 02, 2016, 01:19:12 AM
I have a similar question: is the Merckle trie the most efficient data structure for blockchain management or might there be a more efficient radix trie?  This is something that has been rolling around in my thoughts lately....Has there been any substantial study done on developing a more efficient system, either real or theorized?
A "merkle tree" is what you need to cryptographically harden a tree. The words "merkle tree" do not say much about the particular tree construction being used.

Most efficient for what?  For simply showing membership, which is all it's used for in Bitcoin, it's very hard to even match a plain binary tree (we do not use a trie) with anything else.

For doing other things, many other kinds of data structure have been proposed at various times.

Quote
I've been thinking Mandelbrot functions....Anything on that?
Perhaps you were looking for the ethereum blog? Please don't waste our time here by asking about random semi-relevant collections of technical terms. ("Hey guys, have you considered using a post-quatum NoSQL skip-list?!? I hear it has webscale!")

8  Bitcoin / Development & Technical Discussion / Re: SegWit is a waste of disk space? on: May 02, 2016, 01:03:14 AM
When hashing the transaction data to generate a txid, simply skip over the signature data.  Everything else stays the same.  
You still must have the block commit to the signature, or otherwise the signatures use in the network can be changed. (e.g. I could go add 200 GB to the size of the chain I give you by adding a megabyte of padding to the signatures in the first 200k blocks).  You also need all transaction relay to be changed to be in terms of a new ID which is the hash of the whole transaction, not the txid. (Otherwise I can take a transaction, corrupt the signature, and relay it to everyone fast to block the real transaction from the network.)

And when you've done that, tada you have segwit (specifically, you get the _exact_ construction that was used in elements alpha).  But a version of it with a ugly construction that requires every Bitcoin speaking program to upgrade _simultaneously_, and invalidates any pre-created nlocktimed transactions which _will_ confiscate some amount of users' Bitcoins (because some parties have been signing payments then destroying private keys as a time-lock-safe mechanism).

So what happens with transactions that are unconfirmed when that happens? Sure the idea of it sounds simple, but deploying such a hard fork would be a major clusterfuck.
Exactly, thats why we were unable to go forward with the original segwit design that we used in elements alpha: It's nearly impossible to deploy. The improved design is just simply better and a big part of that-- though far from all of it-- is that it's actually deployable.
9  Bitcoin / Bitcoin Discussion / Re: This just in: Roger Ver can't even transact bitcoin properly on: April 30, 2016, 01:57:55 AM
He used the same input as a previous tx with no miner fee attached.
On two geographically separated nodes.


2016-04-29 12:17:38.592289 got inv: tx 566f0c015a25adf9a29452b29ae7959013b53cc9091566026b14e35ea30ecf8a  new peer=47
2016-04-29 12:17:38.592342 askfor tx 566f0c015a25adf9a29452b29ae7959013b53cc9091566026b14e35ea30ecf8a  0 (00:00:00) peer=47
2016-04-29 12:17:38.741549 566f0c015a25adf9a29452b29ae7959013b53cc9091566026b14e35ea30ecf8a from peer=47 was not accepted: mempool min fee not met, 0 < 306 (code 66)


2016-04-29 12:17:38.692177 got inv: tx 566f0c015a25adf9a29452b29ae7959013b53cc9091566026b14e35ea30ecf8a  new peer=8180
2016-04-29 12:17:38.692226 askfor tx 566f0c015a25adf9a29452b29ae7959013b53cc9091566026b14e35ea30ecf8a  0 (00:00:00) peer=8180
2016-04-29 12:17:38.887028 566f0c015a25adf9a29452b29ae7959013b53cc9091566026b14e35ea30ecf8a from peer=8180 was not accepted: mempool min fee not met, 0 < 326 (code 66)

(Timestamps are UTC)

Because the fee was so low it was instantly dropped-- the Bitcoin Core 0.13 CPFP wouldn't have helped.
10  Bitcoin / Technical Support / Re: Core Client Questions on: April 29, 2016, 04:16:56 PM
If you modify or delete the file you may lose the settings in it.. thats it.

You can increase the keypool at any time. Additional keys will be added the next time you unlock it if it's encrypted.
11  Bitcoin / Bitcoin Discussion / Re: BitClub's fake offer to return fee blunder on: April 28, 2016, 04:52:11 PM
It is possible for Bitclub to have inserted the transaction into their block (without transmitting over the network to other miners).
This was not the case. My node had the transaction for over three minutes before the block. It also heard from of the transaction from more than two dozen peers before the block, If you have logging turned up enough to see it-- you'll see you did too.
12  Bitcoin / Development & Technical Discussion / Re: Speeding up signature verification on: April 27, 2016, 08:30:18 AM
"Using the PCLMULQDQ instruction, the performance of ECC can be
boosted significantly on a range of IA processor cores, making it an
attractive option over other public key algorithms."
Not irrelevant, the 'carryless multiply' is useful for characteristic-2 ECC, which only crazy people would use.

There are also some newer "regular" instructions that might be useful for speedups (mulcx, adcx, adox): http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/ia-large-integer-arithmetic-paper.pdf

Quote
MULX Instruction
ADCX/ADOX Instructions
Yes, these are somewhat useful... but are only in very new processors. E.g. I just got broadwell-ep chips that support ADCX a couple weeks ago (release april 1st). But they don't let us do things efficiently with SIMD, they just would likely make the existing approach somewhat faster if we use them.

13  Bitcoin / Development & Technical Discussion / Re: Speeding up signature verification on: April 26, 2016, 04:45:49 AM
Is there any downside in using SIMD instructions (loading multiple values in different segments of the same registers and performing "packed" SSE/AVX instructions for the math operations) to batch-process multiple signatures per thread?

It would theoretically get the cpu cycles per round much lower than doing it in a serial manner.
You lose the 64,64->128 widening multiplies. The net result appears to be a loss of performance.

If someone was able to get the field arithmetic to operate usefully in parallel there wouldn't be a need to perform multiple verification at once to get performance gains; fwiw.

But actually getting it to be faster while losing the wide multiplies appears to be elusive. Even in the AVX-512 integer stuff I do not see a quadword multiply.



14  Bitcoin / Development & Technical Discussion / Re: Turing completeness and state for smart contract on: April 24, 2016, 07:42:18 AM
This problem doesn't arise when we write smart-contracts for Bitcoin/Ethereum.
Yes it does. A 'smart contract' that never interacts with anything outside the network (including users) is pointless. The smart contract itself may not set the history rewrite, but the possibility of them must be accounted for in the design of the contract.
15  Bitcoin / Development & Technical Discussion / Re: Turing completeness and state for smart contract on: April 24, 2016, 06:53:47 AM
Writing smart contracts is inherently not 'natural' software development similar to how writing legal contracts are not 'natural' prose. The requirements and implications are quite different.

The kinds of data the software works with is different. The resource costs are radically different. The execution environment is necessarily very different-- how often do you write ordinary programs whos execution gets rolled back in a reorg or could "run out of gas"? The implications of failure are typical fairly different. The interactions with privacy are very different than ordinary software development.

Often the "simply written" smart contracts are grievously insecure-- I guess you could say that they're not that smart. Smiley

There can be cases for wanting to use legacy software in a smart contract context, for interoperability or rapid prototyping-- but the ethereum model isn't particular good for that either (it imposes enormous overheads on software compiled from traditional languages).

Effectively, when you create a de novo smart contract you are designing a cryptographic protocol. It turns out that it's fiendishly hard to do this, even for experts, and the science of creating good tools for it is yet unsolved. (Though it's one of the long term problem areas that I'm funding people to work on.)

I think the Bitcoin technical community has some good starting premises about what kinds of constructs facilitate making tools that make it more feasible to construct new smart contracts with less than super-human effort-- things like having top level building blocks that work like monotone boolean functions, so that you can safely compose standardized parts without understanding the internals and your software can reliably analyze the space of possible outcomes.
16  Bitcoin / Development & Technical Discussion / Re: SegWit is a waste of disk space? on: April 24, 2016, 06:19:32 AM
We need profit.
Pump at all costs altcoins are ----> over there.

Quote
Why do we need solution for the thing what is not a problem?  Grin
It's a problem for some things and not others. The fact that whatever you're doing might not be bothered by it isn't a reason that it shouldn't be fixed for others that care about it.
17  Bitcoin / Development & Technical Discussion / Re: SegWit is a waste of disk space? on: April 24, 2016, 06:14:15 AM
segwit makes individual transactions bigger.
It does not. (unless you want to count a byte or two from flagging in particular serialization which could simply be compressed out, if anyone cares).

You should read the FAQ: https://bitcoincore.org/en/2016/01/26/segwit-benefits/

Key advantages include solving malleability, facilitating safe script upgrades, lowering resource usage for lite clients, allowing additional capacity without significant additional UTXO bloat risk (in fact, it largely corrects the issue that creating additional UTXO is significantly cheaper than cleaning them up). In doing so it significantly reduces some of the risk points in increased capacity.

Quote
saying you don't need the segwit data is the equivalent of saying SPV mining is OK
The network consists of more than just miners, segwit doesn't change the data miners need. Allowing a continuum of options in using the network is important for avoiding some users being 'priced out' by the operating cost of it.

Quote
As for malleability, so anyone wanna say why that can't be done properly on it's own without segwit?

Segwit is the only proper solution for malleability. The only other alternative is long lists of canonical encoding rules-- a mess of bandaids which, at best, only solve it for a subset of transaction types-- and even then maybe not (it's very hard to be sure that a set of canonical encoding rules is actually sufficient to guarantee non-malleability). That kind of patchy approach is a huge pile of technical debt that would make it much harder to implement and maintain the consensus code in Bitcoin implementations.
18  Bitcoin / Development & Technical Discussion / Re: Will Schnorr signatures be able to give us default "CoinJoined" transactions? on: April 23, 2016, 10:09:49 PM
Schnorr sigs will deliver a more efficient way to deal with this stuff.
[...]
When we will be able to start a "roadmap to fungibility"? like a transition from the current standard transaction model, to the next standard ("CoinJoined") transaction model? Because that's what we should do as soon as possible.
This should be a top priority imo. Lets not forget that Bitcoin is supposed to be p2p cash so this is a must to reach that definition, so like I said before, default state of a transaction should be Coinjoin and CT enabled for everyone, unless you want to be transparent in purpose.
The only reason our schnorr sigs will have that property is because Adam Back, Pieter, and myself have been working on it-- this kind of aggregatability isn't something that would just automatically come from schnorr, it requires a special design.

We consider it a priority, but it's only with the advent of segwit that it becomes sufficiently easy to deploy these improvements that I can be pretty confident of getting them in (and rather than having them end up as a marketing point in some altcoin.).  Segwit isn't in the network yet, and there is still a sizable "online" force of people attacking it, the folks working on it (and on general fungibility) improvements-- which makes it harder to give concrete schedules.

I'd like to say that I expect to get aggregateable schnorr into Bitcoin in the next year; but that depends on a multitude of factors that are hard to predict and that I can't control.
19  Bitcoin / Development & Technical Discussion / Re: Turing completeness and state for smart contract on: April 23, 2016, 10:01:15 PM
It's state that matters. You can't have true interoperability without it.
That also seems confused to me. Bitcoin and Bitcoin smart contracts have state-- if they didn't they wouldn't work at all. But rather than having sprawling state that requires random access to the system and hiding the true cost of providing this state, Bitcoin transactions flow state information from inputs to output.

The result is a model which is more like monads in purely functional languages: A transaction collects some state (txin selection), creates new state (new txouts), and the scriptsig/witness proves that the state transition was permitted.

Similarly to the move to thinking in terms of verification instead of computation, this insight often permits transformations that improve scalablity.  E.g. instead of storing the state explicitly in outputs, in some applications you can store a hash tree over the state; then subsequent actions can simply show access and update proofs. This kind of compaction can't be used in all cases, but where it can it's very efficient.  I spoke some of these advantages on the subject of code above (e.g. MAST), but they apply no less for state.

An example of elided state, a simple one without state updates, is https://blockstream.com/2015/08/24/treesignatures/ which shows the construction of fairly efficient, pretty private, accountable multisig that avoids putting all of the applicable public keys into the blockchain.

The advantages of this kind of construction will be more clear to more people as future script enhancements restore functionality in Bitcoin script that was disabled; which will bring back the ability to enforce constraints on state carried from inputs to outputs.
20  Bitcoin / Bitcoin Discussion / Re: MIT ChainAnchor - Bribing Miners to Regulate Bitcoin on: April 22, 2016, 05:13:52 PM

Quote
Here ChainAnchor is deployed as an overlay above the current public and permissionless Blockchain. The goal of the overlay approach is not to create a separate chain, but rather use the current permissionless Blockchain (in Bitcoin) to carry permissioned-transactions relating to Users in ChainAnchor in such a way that non-ChainAnchor nodes are oblivious to the transactions belonging to a permissioned-group. We use the example of the current Bitcoin blockchain as the underlying blockchain due to the fact that today it is the only operational blockchain that has achieved scale.
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 ... 223 »
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!