Bitcoin Forum
April 26, 2015, 10:31:57 PM *
News: Latest stable version of Bitcoin Core: 0.10.0 [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 ... 197 »
1  Bitcoin / Development & Technical Discussion / Re: variance in block times --- std deviation on: April 24, 2015, 10:05:59 PM
Block finding is just a poisson process; its variance of the intervals well defined-- 1/(lambda)^2; and thus the std dev is the same as the mean.  Observed empirical variance will be slightly different due to shot noise, changes in hashrate, etc... but close enough.

It's important to keep in mind that the variance is a necessary component; without variance the network would never converge again after a fork.
2  Bitcoin / Development & Technical Discussion / Re: Likelihood of transaction hash mutating with current state of BIP062 on: April 22, 2015, 06:47:56 PM
Can you explain this?
(without resorting to anything that can't be clearly understood by most people)
The pledges model used for lighthouse is that you author a transaction paying you some amount but not supplying the coins, then people can supply signatures for their coins at their leisure and they can be merged by anyone in any order without interaction. Once enough coins are provide the transaction can go through.  These additional signatures are modifications of the transaction.

We have the sighash flags specifically to _allow_ malleability.

Absent this, you'd need something more like a realtime coinjoin server; which is much less usable; all the users would have to agree in advance on all the participants and all be online at basically the same time, and all would have to coordinate through a server, and if anyone dropped out before signing the process would have to restart.

3  Bitcoin / Development & Technical Discussion / Re: Likelihood of transaction hash mutating with current state of BIP062 on: April 22, 2015, 06:25:48 PM
cannot be mutated
by third parties.
4  Bitcoin / Development & Technical Discussion / Re: Coinjoin improvement..? on: April 22, 2015, 05:43:50 PM
doing so seems to have been a huge success, recent research suggests that coinjoins are now a pretty substantial chunk of the activity on the network.

Is this research published anywhere?

But.. Hm. Her slides for this had usage figures that don't appear to be in the paper, I'll see if I can find them.
5  Bitcoin / Development & Technical Discussion / Re: Semi-soft-fork to decrease the risk of tx malleability on: April 22, 2015, 05:42:02 PM
It would make it easier to do the soft fork checks in code. 
It would make it easier to do them wrong.  You're expecting change A, but the network has adopted B.  You're now confused.  That kind of simplistic check is only safe with a centralized process providing a universal order of changes; and to provide that non-safety it has to use up a fair amount of precious space.

Compared to the rest of the complexity of checking headers I don't see keeping 15 counters a list of completed changes to be a major barrier.

It would still need 95%+ support for miners.
It's much easier to get 95% hashrate (not that this isn't 95% people or anything like that) for a very profitable blank check.
6  Bitcoin / Development & Technical Discussion / Re: Coinjoin improvement..? on: April 22, 2015, 09:10:09 AM
He gave you a nice link that explains blind signatures; and he explains how they're used for this.  Any blind signature scheme works for that usage, and a regular schnorr signature (which works fine with the secp256k1 group) can be easily blinded. Please don't waste peoples time by having them explain well known cryptographic tools, especially when they already handed you an adequate link. It is disrespectful to others here to ask them to burn their time rather than trying for a few more moments with your own to actually understand what is being presented before just turning around and arguing with it.

You say the participants submit to the server their outputs... right there; a bitcoin output is your address - so if that is what you submitted, the server will know exactly where each participant wants their money to go

Please see step 2 in the post, it addresses this specifically. They reconnect anonymously (or send their messages over mixmaster or bitmessage or whatever you like).  The server has no idea how the new participants are at all related to the old ones; the server learn nothing more than someone observing the transaction on the network would (except greater confidence that it was a CoinJoin at all).

if the server knows
The server doesn't know, that is the purpose of the blind signatures-- all the participants know that the outputs came from a valid participant, but not which participant they came from. Making the operation private from the server is what accomplished by the protocol described at a high level above.  No blind signatures are required to make things private from the other participants, that just happens automatically.
7  Bitcoin / Development & Technical Discussion / Re: Semi-soft-fork to decrease the risk of tx malleability on: April 21, 2015, 10:24:26 PM
So, version becomes non-monotonic?
Correct. And why shouldn't it be? It's just data. An expectation of monotonicity is not very compatible with decentralization in any case.

What about 2 bytes for "count" and 2 bytes for softforks.
If a soft-fork is accepted, the "count" part of the version increases by 1.
If the count is made the top 2 bytes, then the version will increase as each soft fork is accepted.
What would this gain? You can already count the acceptance from the flags, even if you don't know what they mean.

We'd want to use the remaining bits for extra information that needs to be judged statelessly, without seeing the prior headers. (there are very few cases where this matters, but e.g. additional POW constraints, for soft-forking in an additional POW, would be an example).

A warning to update has the risk of everyone updating their client at the same time.
Not a warning to update-- but notice that the network is imposing rules that your software doesn't understand, meaning that it might accept a fork the overwhelming majority of the hashpower on the chain you're on would not accept.   Such a notice would only happen around the point the new rules went into effect in any case; e.g. once its already widely deployed.

If the consensus lib was based on a virtual CPU with bytecode, the new soft rule could potentially be added as part of the process.  That might make it too easy to add soft forks though.

That could only safely work for rules that didn't lock in, since they could only really safely be applied in the context of a single chain.  Keep in mind, a big reason for the rules a node imposes exist to create a reason for miners to behave honestly; the purpose of it is to constrain their behavior, so giving them control over it doesn't make sense.  A soft-fork isn't a vote; its safe coordination for activation of a change that people already (almost certainly) consent to. The whole reason to have it isn't to decide to do it or not, but to make sure that everyone imposes it at the same time.

8  Bitcoin / Technical Support / Re: Bitcoin Core, can't sync. Receiving wrong header/blocks? on: April 21, 2015, 08:13:20 PM
Nothing was wrong on my end, there seems to be malicious nodes out there.
A bit disappointing that I had to figure this out myself and nobody gave any good advice.
You're asking the wrong question. There is nothing a malicious node can do to harm you, you should not have to manually control who you're connecting to, and doing so with connect is likely to leave you constantly dysfunction unless you're connecting to nodes you control on your own.

Your blockchain data was becoming corrupted; this doesn't have anything to do with your peers; its either due to your hardware or a software bug. You do not generally need to redownload to recover from corruption, reindex does that. Unfortunately there is a bug in 0.10.0 where reindex can cause corruption; it's fixed in 0.10.1rc available at  and which will be made a full release in a few days (sooner if there are success reports from people using it).
9  Bitcoin / Development & Technical Discussion / Re: Questions about Lighthouse Transactions on: April 21, 2015, 07:40:25 PM
Lighthouse is all or nothing funding;  nothing stops the pledges from being withdrawn at all, or even really discourages it (beyond the basic software behavior)--- the fact that they can be is a reason to hurry up and get your pledge in so the funding can go through. If one is withdrawn you take it out of the transaction and find a replacement source of funds.

Without the ability to modify transactions once signed what lighthouse does would just be impossible... to be able to add new participants without knowing in advance who they are you must be able to change the transaction.

10  Bitcoin / Development & Technical Discussion / Re: Semi-soft-fork to decrease the risk of tx malleability on: April 21, 2015, 06:18:25 PM
It will be exhausted very soon if it is used in this way, isn't it?
No, because the bit becomes available for use again after the feature latches or passes the deadline without latching;  So up to 31 features in flight at once, and no total limit (though we might reduce it to just 15 of the bits being used in this way).

If the soft-fork rules are consistent even for yet undefined future soft-forks then even a non-upgraded client can tell what the state of the softfork is even without knowing its specifics.

I'm not sure if I misunderstand you. In the refund protocol, the potential attacker (i.e. the payee) does not need to sign the payment to the escrow address. It should work like this:
Depends on what you mean by refund protocol. As soon as your pattern makes multiple transactions-- e.g. the escrow makes change back to the escrow, things are broken again.
11  Bitcoin / Development & Technical Discussion / Re: Semi-soft-fork to decrease the risk of tx malleability on: April 21, 2015, 05:17:08 PM
But in the BIP66 description it says it "has the added benefit of reducing transaction malleability":
Sure, its a forward move of one of the BIP62 features; but "reducing" doesn't improve anything; it's not like malleability happens by chance.

And if a non-compliant signature can trivially be converted into a compliant one (I assume private key is not needed for such conversion?), why isn't it a source of malleability?
Because only the single canonical form is permitted in the blockchain.

And the selling point is low risk, not low cost.
The amount of code that must be written and confirmed to be correct is the risk, and the risk is the cost.

An ordinary soft-fork is not especially risky so long as the work is done to be confident that its engineered correctly; and virtually all the risk comes from the definition of the restriction itself; there was an inflow of virtually no review or commentary for BIP66.

Can we deploy 2 (or more) soft-fork concurrently like this: block version 3 is BIP62 only; block version 4 is BIP66 only; block version 5 is both BIP62 and 66?
Not with the current definition for the mechanism used in BIP62. Version 5 would enable BIP 62 on existing nodes.

Pieter has a new proposal which makes major improvements: every softfork is signaled by a single bit, the when the bit crossed threshold it 'latches' and
becomes available for reuse again, and there is a deadline by which if it fails to latch its aborted and becomes available for use again.

We wanted to use that for BIP62 but it would have delayed the process.

Keep in mind, that for refund protocols where the potential attacker is a signer of the transaction no "fix" in the form of signature encoding improvements is possible; their problem is not that transactions are malleable but that the malleability matters. BIP66 is about preventing (we hope) third party malleability.
12  Bitcoin / Development & Technical Discussion / Re: Semi-soft-fork to decrease the risk of tx malleability on: April 21, 2015, 09:32:54 AM
we have BIP66 but there are still many forms of malleability to be fixed.
BIP66 is not about malleability, really; BIP62 is.

What you're describing has previously been described as "Block discouragement";  here I think it has all the software complexity of a normal soft-fork plus the additional complexity of the discouragement mechanism.

I do not see how this helps much; the reversibility is a selling point, but at a far from zero cost. We'll be moving on 62 once 66 is actually deployed (one flaw in the the legacy softfork deployment mechanism is that only one change can be in flight at a time)
13  Bitcoin / Development & Technical Discussion / Re: Salvaging refund protocols from malleability attacks with P2SH on: April 21, 2015, 07:49:32 AM
My question a year ago has not been answered. As someone may attack the network by randomly mutating txs, just like what we had last year, no txid should be considered as final before it is written in the blockchain.
What to answer? That was the limitation here-- pointed out in the post; someone might choose to take that risk-- e.g. if their alternative is to just trust their counterparty instead such a scheme could only be an improvement.
14  Bitcoin / Development & Technical Discussion / Re: Bitcoin-QT bypassing Tor on: April 21, 2015, 12:15:58 AM
No reason to panic, lets just investigate.  There have been leaks in the past but I'm not aware of any right now; doesn't mean there aren't any.   Are the DNS servers your host is using any of those IPs?  do those IPs get mentioned at all in your debug.log?
15  Bitcoin / Technical Support / Re: Rescan on btcd and bitcoind gives a different set of unspents on: April 20, 2015, 04:45:37 PM
Feel like testing a patch?

Also PRed at:

diff --git a/src/wallet/rpcwallet.cpp b/src/wallet/rpcwallet.cpp
index e03cd5b..c31c09d 100644
--- a/src/wallet/rpcwallet.cpp
+++ b/src/wallet/rpcwallet.cpp
@@ -2301,7 +2301,7 @@ Value listunspent(const Array& params, bool fHelp)
     vector<COutput> vecOutputs;
     assert(pwalletMain != NULL);
     LOCK2(cs_main, pwalletMain->cs_wallet);
-    pwalletMain->AvailableCoins(vecOutputs, false);
+    pwalletMain->AvailableCoins(vecOutputs, false, NULL, true);
     BOOST_FOREACH(const COutput& out, vecOutputs) {
         if (out.nDepth < nMinDepth || out.nDepth > nMaxDepth)
diff --git a/src/wallet/wallet.cpp b/src/wallet/wallet.cpp
index 2566b27..1ed0c03 100644
--- a/src/wallet/wallet.cpp
+++ b/src/wallet/wallet.cpp
@@ -1481,7 +1481,7 @@ CAmount CWallet::GetImmatureWatchOnlyBalance() const
  * populate vCoins with vector of available COutputs.
-void CWallet::AvailableCoins(vector<COutput>& vCoins, bool fOnlyConfirmed, const CCoinControl *coinControl) const
+void CWallet::AvailableCoins(vector<COutput>& vCoins, bool fOnlyConfirmed, const CCoinControl *coinControl, bool fIncludeZeroValue) const
@@ -1508,7 +1508,7 @@ void CWallet::AvailableCoins(vector<COutput>& vCoins, bool fOnlyConfirmed, const
             for (unsigned int i = 0; i < pcoin->vout.size(); i++) {
                 isminetype mine = IsMine(pcoin->vout);
                 if (!(IsSpent(wtxid, i)) && mine != ISMINE_NO &&
-                    !IsLockedCoin((*it).first, i) && pcoin->vout.nValue > 0 &&
+                    !IsLockedCoin((*it).first, i) && (pcoin->vout.nValue > 0 || fIncludeZeroValue) &&
                     (!coinControl || !coinControl->HasSelected() || coinControl->IsSelected((*it).first, i)))
                         vCoins.push_back(COutput(pcoin, i, nDepth, (mine & ISMINE_SPENDABLE) != ISMINE_NO));
diff --git a/src/wallet/wallet.h b/src/wallet/wallet.h
index 4dbb0e2..c5f876f 100644
--- a/src/wallet/wallet.h
+++ b/src/wallet/wallet.h
@@ -540,7 +540,7 @@ public:
     //! check whether we are allowed to upgrade (or already support) to the named feature
     bool CanSupportFeature(enum WalletFeature wf) { AssertLockHeld(cs_wallet); return nWalletMaxVersion >= wf; }
-    void AvailableCoins(std::vector<COutput>& vCoins, bool fOnlyConfirmed=true, const CCoinControl *coinControl = NULL) const;
+    void AvailableCoins(std::vector<COutput>& vCoins, bool fOnlyConfirmed=true, const CCoinControl *coinControl = NULL, bool fIncludeZeroValue=false) const;
     bool SelectCoinsMinConf(const CAmount& nTargetValue, int nConfMine, int nConfTheirs, std::vector<COutput> vCoins, std::set<std::pair<const CWalletTx*,unsigned int> >& setCoinsRet, CAmount& nValueRet) const;
     bool IsSpent(const uint256& hash, unsigned int n) const;
16  Bitcoin / Development & Technical Discussion / Re: Bitcoin-QT bypassing Tor on: April 20, 2015, 04:44:24 PM
Thats not very informative; is there a way to tell if that isn't an _inbound_ connection that someone is trying to make towards you?

100.64/10 is reserved private address space and not generally routable on the internet; see RFC 6598.
17  Bitcoin / Development & Technical Discussion / Re: Extracting the Private Key from a TREZOR ... with a 70 $ Oscilloscope on: April 19, 2015, 09:09:46 PM
Looks that it is claims to be protected against all of these attucks
Unlikely.  Power filtering cannot help you when the leak is so gross that it makes timing differences you could darn near measure with a stopwatch.

Though the device looks pretty interesting and would be good for applications where the software is already largely protected! But the invest page makes it severely smell like a scam.
18  Bitcoin / Technical Support / Re: Rescan on btcd and bitcoind gives a different UTXO set on: April 19, 2015, 05:12:45 PM
Zero amount outputs can be spent; a bitcoin transaction need not involve any bitcoins-- this is part of the premise by which some of these embedded consensus altcoins hope to replace the Bitcoin currency.. They're non-standard to create, so they need miner cooperation.

Now I'm extra interested, since that sounds like a bug unless they're actually unspendable for some other reason.
19  Bitcoin / Development & Technical Discussion / MOVED: Rescan on btcd and bitcoind gives a different UTXO set on: April 19, 2015, 07:32:46 AM
This topic has been moved to Technical Support.
20  Bitcoin / Development & Technical Discussion / Re: Likely misspellings in source files? on: April 19, 2015, 02:56:29 AM
Where are you looking? git grep on a current checkout shows me no bitconi, though the bitcon (a dreadful mistake that I've made a number of times myself-- had a laptop with a lossy keyboard) is still in src/qt/locale/bitcoin_da.ts though not elsewhere.
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 ... 197 »
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!