Also, A lot of hardware only searches a subset of nonces. The size is irrelevant; it's just roughly the soft target most miners use... the size isn't even available to the mining algorithm, which works only on the block header, other than being the amount of data after a dozen layers of sha256 that feed into the tree root hash in the header. |
|
|
|
You are spamming; advertising your product is off-topic for this thread, doubly so since its already been spamvertised once here; but since you've been so bold-- I inquired and found out that your product is based off the same weak, barely tested/reviewed, and slow as heck naive cryptographic code used in the product being discussed here. The information leak here is so severe that I am very doubtful that your (quite laudable) improved hardware isolation can prevent-- e.g. the code in question leaks several bits of information about the key from just the time it takes. Furthermore, Your "directly in silicon" is an FPGA with a loading procedure 'under the seal', this is potentially yet another back door vector, it sinks a lot of power, and really seems to be of dubious value. I would have preferably seen all the external interfaces over simple low-ish-speed serial interfaces with good electrical isolation, rather than a huge power sucking FPGA under the secure-area can. Use of a BGA probably also means you need a 4 layer board for signals routing and thus probably can't use an extra layer as a separate ground to complete the shield can. The FPGA just seems like a costly gimmick to me, and that you're misrepresenting this as a solution to bad cryptographic code (which you have made a similar failure by selecting to use it) doesn't bode well for the security of your product. |
|
|
|
|
No restrictions can be placed on scriptPubKeys or redeemscript-content without potentially confiscating people's Bitcoins.
|
|
|
|
Is there any consensus that CHECKLOCKTIMEVERIFY will be implemented??
Everyone who has commented has spoken up in favor of it, and plenty of people have. So I think so. Is the plan BIP-66 then BIP-62 and then OP_CHECKLOCKTIMEVERIFY?
66 is in flight and must finish before another softfork can be undertaken. I'd like further softforks to switch to the new softforking system that doesn't require serializing things. If you'd like to see faster progress; please go nag miners to upgrade to 0.10.1. |
|
|
|
|
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.
|
|
|
|
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. |
|
|
|
cannot be mutated
by third parties. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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 https://bitcoin.org/bin/bitcoin-core-0.10.1/test/ and which will be made a full release in a few days (sooner if there are success reports from people using it). |
|
|
|
|
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.
|
|
|
|
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. |
|
|
|
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. |
|
|
|
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) |
|
|
|
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. |
|
|
|
|
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?
|
|
|
|
Feel like testing a patch? Also PRed at: https://github.com/bitcoin/bitcoin/pull/6036
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)
continue;
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
{
vCoins.clear();
@@ -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;
|
|
|
|
|
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.
|
|
|
|
|
Show Posts
