Bitcoin Forum
May 30, 2017, 11:16:27 AM *
News: If the forum does not load normally for you, please send me a traceroute.
 
  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 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 ... 237 »
481  Bitcoin / Development & Technical Discussion / Re: Delayed Replace By Fee (RBF) on: December 04, 2015, 11:45:10 PM
Satoshi would be disgusted.
If so why would the system's creator have put opt-in unconfirmed transaction replacement into the very first release of Bitcoin?
482  Bitcoin / Bitcoin Discussion / Re: Bitcoin XT - Officially #REKT (also goes for BIP101 fraud) on: December 03, 2015, 08:25:32 PM
It's good that instrumentation and controls are coming.  IMO they are a couple years late.
I must have missed your contributions...  Less snarkily, they required upgrades to the commonly deployed p2p behavior before they could be deployed.

Quote
If done right, controls would not slow down getting current blocks.
Right now they don't; though later resource limits will also be able to limit at the tip (as a last ditch option-- we'd rather have a slow node than no node.)

Quote
It would be entirely reasonable to charge newbies a fee to offset these real costs.
And guarantee a loss of decentralization. No thanks. But the costs of bringing up new peers should rest on those who have plenty of resources and don't mind spending them on that... and it's much closer to that now in 0.12.

Quote
As to constant factors.  They are easily dismissed by theoreticians. Practical people who design, deploy, manage and operate businesses that provide cloud computing services live or die by small percentage changes in constant factors.
Agreed.  One of the most regrettable things about this block-size snafu in my view is this characterization of 800% or 2000% increases as "modest" or a _doubling_ as being too small to consider. Some people talk in terms of "plan for success", but can't seem to accept the possibility that the system will successfully respond to demand and capacity without removing resource limits in advance. 

Quote
In this case, it appears that there are tremendous opportunities for two types of improvements here.  First, in reducing the amount of data that an operational node needs to transmit and receive, and second in tuning the nodes and their networking environment to effectively utilize the available resources.
Absolutely, and that's what being done; more help is always welcome.

Is there more data behind the plot?  It would be useful to look at the distribution and the performance for specific pools vs. the topology involved, including machines and link rates. (I can appreciate that some of this data may be proprietary or otherwise unavailable.)

I have detailed per pool data; but I would prefer to not publish information that could be used for competitive comparison because there are various ways to cook the results, including ones which are bad for the network (in particular always perform verification free / SPV mining). E.g. if bar pool feels pressure because it's slower than foo pool, it'll switch to spv mining.  The information broken down by pool is pretty noisy, because many find fairly few blocks.   There are performance differences, though the spread isn't huge over most of them; there is one or two that reliably perform quite poorly-- and these end up always excluded by that "time to reach half pools" metric.

I did all manner of multifactor analysis; including checking an IsChina effect and considering all pairwise pairs.  IsChina in aggregate didn't have a statistically significant effect when also considering the individual pool performance. Likewise, none of the pairwise parameters rose to significance. A couple of the pools have a statistically significant this-pool-sucks effect; but per pool bandwidth numbers didn't differ significantly from the mean overall (I assume more due to not having enough data, and because the impact depends both on block sources and destinations, rather than no effect).

Quote
I can speak from personal experience as a small scale miner.  Last summer I was solo mining with two S3s that I was still running despite the heat and managed to score a block on solo.ckpool.org.  The 0.5% fee was well worth it for use of a high bandwidth connection, because the orphan risk out of my DSL based home office would have been unacceptable.  (You might ask, why was I solo mining?  That's a another question, but it certainly looked like some of the pools had a consistent run of bad luck indicating that something was seriously wrong.)

FWIW, P2pool integrates an efficient relay mechanism similar to the relay network client protocol. In spite running on all manner of home equipment; it had the lowest orphan rate of any pool back when it had enough hashrate to measure it; you can quasi solo on it by turning your share difficulty all the way up to 1/10th the block difficulty.
483  Bitcoin / Bitcoin Discussion / Re: Bitcoin XT - Officially #REKT (also goes for BIP101 fraud) on: December 02, 2015, 07:26:28 AM
Bigger blocks (with at least some reasonable upper bound) make spam attacks more expensive, as tx's drop out of the mempool and fees can be recycled continuously.
Not so much, in that the fee required to get into the mempool in the first place goes up as transactions are dropped out; at least with the limited mempool in 0.12.  To the extent that a bigger block makes spam attacks more expensive it's only really through the action of making it much cheaper to inflict additional storage-in-perpetuity on the network. So far, the non-trivially funded spam attacks that we've seen have not been successful in driving the feel levels required to bypass them above negligible cents per transaction levels (e.g. significantly cheaper than what credit card networks charge merchants per transaction).... though obviously this has limits.

Right now, measuring the differential time it takes for mining pools to switch the blocks they're working on vs block size suggests an effective transfer rate of 723kbit/sec (less shockingly slow when you consider how inefficient TCP is for bursty conditions across links with worldwide latency), This is the amount of time it took for a block to reach half the monitored public pool's stratum endpoints after reaching the first one vs blocksize:  https://people.xiph.org/~greg/sp2.png  (Matt more recently did a similar measurement of relay network behavior and reached a similar but somewhat lower throughput).   If you take that offset (2.491s) and data rate, and drop it into formula for subsidy income loss cost for the last byte of a megabyte block, the break-even feerate is 0.00045054 BTC/KB. So that suggests that at least lower hashrate miners are accepting transactions at a price low enough to be a net-loss currently. (It may not be the case; e.g. if the low hashrate miners are all fast. and the high hashrate miners are all slow, or low hashrate doesn't process as many transactions; and the data is all over the map... etc.)
484  Bitcoin / Bitcoin Discussion / Re: Bitcoin XT - Officially #REKT (also goes for BIP101 fraud) on: December 02, 2015, 02:20:50 AM
From a little watching of my connection activity, I observed that a lot of the upload bandwidth was loading older blocks.  A limit on bandwidth provided for uploading older blocks would certainly help.
Implemented in Bitcoin Core git master a couple months ago, will be in 0.12; along with many other resource control tools. Though if widely used it will further congest getting blocks to begin with. It's a good trade-off, but not without costs. None of this is magic: cutting down this source of traffic or that is mostly just constant factor reductions. To operate the system needs a safety margin, and we're bumping up against actual limits.

Not sure what happened with that, looks like it didn't make it into 0.12, but perhaps I'm not looking hard enough. Or maybe there was a good reason not to include it (apparently network message anti-spamming measure did make it into 0.12)
You weren't looking hard enough Smiley, it's called -maxuploadtarget   see also doc/reduce-traffic.md (though not all of the features are documented yet).   (amusingly, this was one of the relatively few PR's that Mike Hearn commented on-- opposing it.)

That does not mean I think the crowd will choose big blocks, it means that I think if bigger blocks are needed then I think that something will happen to ensure that bigger blocks happen.
This was one of the big fallacies involved in the "crash landing" spin by Gavin and Hearn; this notion that Bitcoin would willfully commit suicide.  Cranking the scale ahead of addressing scaliablity is/was controversial (not just among the most technical, though it's nearly universal there); but if it were strongly _necessary_, and better than the harm of not; then it would no longer be. That we're not there now, shows it isn't. QED.  And there is a tone of activity gone on to improve scalablity at all levels of the system, from micro optimizations, to protocol design.
485  Bitcoin / Bitcoin Discussion / Re: Bitcoin XT - Officially #REKT (also goes for BIP101 fraud) on: December 01, 2015, 06:35:57 PM
And yet this information is ruthlessly attacked whenever it is pointed out-- I am routinely called a "bitcoin bear" even though I have a significant portion of my net worth tied up in it, simply for beveling in Bitcoin enough to be frank about the problems and limitations in it. Many people less convinced about Bitcoin's power and value than I and much more interested in the short term pump are unwilling to tolerate any discussion of challenges; and this creates a poisonous atmosphere which undermines the system's ability to heal and improve.

https://www.reddit.com/r/Bitcoin/comments/3uz0im/eli5_if_large_blocks_hurt_miners_with_slow/cxj3k01?context=3
486  Bitcoin / Bitcoin Discussion / Re: Bitcoin XT - Officially #REKT (also goes for BIP101 fraud) on: December 01, 2015, 08:06:32 AM
We should not restrict anyone from being able to run a node, nor should we make it much harder (somewhat is acceptable) for those that already are running them, just because a group of 'scoundrel' want to pay for their coffee using Bitcoin.
Nothing wrong for paying for coffee with Bitcoin or even the bitcoin network. But to whatever extent there is a choice between monetary sovereignty and direct blockchain small retail sales-- the latter can be replaced using a lot of different mechanisms (for coffee? even centralized ones, for godssakes!); and the former cannot...   I don't really think there is a fundamental mutual exclusion, but avoiding it will require being smarter, and not just cramming things in. Bitcoin: It's not a big truck.

Of more concern than "coffee" is transactions which have nothing to do with Bitcoin, transfer no Bitcoin value; and are just stuffing data into the bitcoin network because it's available; and some people have been going around selling the idea of ignoring the Bitcoin currency and saying that the system is just a big public database. This sort of stuff is out of scope for the Bitcoin system and endangers it survival when the cost of carting around a zillion 'stock transfer' zero value txouts overwhelms the public's interest in Bitcoin. ... and they've been a major driver for calls to remove Bitcoin's resource controls. I think totally separate assets need to have their own networks and fates, or otherwise one becomes an externalized cost on the other and can act as dead weight that removes the viability of the combined system.
487  Bitcoin / Bitcoin Discussion / Re: Bitcoin XT - Officially #REKT (also goes for BIP101 fraud) on: December 01, 2015, 03:23:27 AM
Wrong, wrong and more wrong.
The 1MB limit was put in place in 2010, not 2008. Actual bitcoin network upload speed (the real bottleneck) measurements show upload bandwidth for nodes at edge of network is growing at closer to 17-25%. (This disregards data caps for total bandwidth available also).

Bitcoin also had a 250kb limit at the time, implemented as a soft-rule by miners rather than a hard protocol rule. If you take the current system with a 2010 client (and much less a circa 2010 computer) it will likely not keep up with the network (if you try, let me know in a month when you complete the initial block download... Smiley Tongue ). The limits then were already set in a forward looking manner and we have been scrambling to keep up with the network as it's grown into them.

get real. you can buy a 1TB harddrive for $50 today and store BIP101-enabled blockchain onto it for years to come. then pay $50 more for a 4TB drive to handle a few more years of growth.  or are you still using the same computer you owned in 1999 with its 1.6GHz singlecore, 512MB ram, and 60GB HDD (all cutting edge)?
This is ignorant of the total costs of operating a reliable production grade system in a commercial environment... including the need to be nowhere near capacity at any time even when run on underspeced/io-starved/misconfigured mystery-meat hosting in order to make sure that nothing especially clever or difficult is required so that you can employ commonly available ham-sandwiches as devops.

This may not be as true for businesses that really consider Bitcoin to be central to their business-- but, as a bitcoin-seriousness proxy, how many non-mining Bitcoin companies do you know of that mine and participate in the network consensus? (I know of only one, ahem; and it seems like in not to long the same may apply for running full nodes)... Ultimately if the system is only usable in a way that preserves its political and security properties by those who are those who are the "most serious" (and politically motivated) then it will not be a success as a decentralized system.  It's not good enough to be accessible to some, to achieve decentralization it has to be broadly accessible.

There are many factors standing in the way of that; including indifference and a lack of education but resource impacts absolutely play a part of it. You don't see people widely outsourcing their DHCP daemons, though they're incidental to their business. Why isn't a Bitcoin node as invisible as a DHCP server? Go show me a DHCP server that uses tens of gigs of storage, hundreds of gigs of transfer, gigabytes of ram, significant amounts of CPU, etc. and all these demands constantly growing.

One of the reasons I think that XT has been as much of a flop as it has, so quickly, is that many of the people persuaded by the eloquent rants of misleading simplicity went and actually ran a Bitcoin node; and encountered the same costs and annoyances that users have been complaining about heavily since the soft limits were cranked... and lost their conviction. I know this is true for some, but I wouldn't be surprised if it were a more general pattern.(I also suspect that many, though probably not all, the people complaining about DOS attacks weren't just seeing the ordinary load that every other node sees; including the "attack like" traffic from people trying to trace transaction origins-- even I thought someone was attacking Core nodes and changed to identify as XT and saw no difference in traffic)... plus the whole, "unlimited blocks are great, so long as someone else is paying the cost", which doesn't actually work...

488  Bitcoin / Bitcoin Discussion / Re: Bitcoin XT - Officially #REKT (also goes for BIP101 fraud) on: December 01, 2015, 12:08:50 AM
You keep saying that it is opt-in however it is only opt-in for the sender not the reciever,
Not so, the merchant can simply ignore the transaction until it is confirmed; as they already do for all manner of unusual, nonstandard, unconfirmed input transactions, etc. or otherwise their acceptance of zero conf is no more secure than RBF (if it ever is...) ... and doing this is relatively harmless, because Opt-in RBF transactions do not need to suffer significant confirmation delays.

Quote
For me it is not even a question of greater expertise since it has also become about ideology relating to economics and politics, these are questions that most technical experts are not specifically trained to answer. I think that some of these more fundamental questions like the blocksize for instance are more concerned with politics and economics then computer science,
You are making a strong and unjustified assumption about the skills and background of people maintaining Bitcoin Core. I think you may be making the fallacy of assuming that a group excellent in a particular area must necessarily be weak in another specific area. The community, even the most active segment, is fairly large and diverse in many ways-- much more so then, for example, the persons working on XT*. Beyond the expected CS and distributed systems PHDs, the community includes people with expertise in mathematics, economics, financial markets, ... Peter Todd has a fine arts degree. Skepticism about the viability of the Bitcoin system absent effective meaningful block size limits can be found in peer reviewed academic publications in economics venues. Negative effects on mining fairness are both predicted by simulation, and borne out in field trials on test networks.

[*As a  vague yardstick, there are ~19 contributors to Bitcoin core with individually more commit count activity in the last six months then all contributors to XT had in both XT and Core combined. Commit count is a crappy metric and you can figure that is off by a large factor in either direction; but this isn't really a comparable; and this is in spite of non-stop attacks that make working on Bitcoin really demoralizing]

And beyond the expertise, we're speaking about a question where in the absence of perfect knowledge we conducted the experiment: We raise the soft blocksize target from 250k to 750k and saw tremendously negative effects: substantial declines in node count (in spite large growths in userbase; and to brag, somewhat heroic efforts to increase software performance), substantial increases in mining centralization, substantial increases in Bitcoin businesses relying on third party APIs rather than running nodes (hugely magnifying systemic risks). We've seen the result and it isn't pretty. And yet this information is ruthlessly attacked whenever it is pointed out-- I am routinely called a "bitcoin bear" even though I have a significant portion of my net worth tied up in it, simply for beveling in Bitcoin enough to be frank about the problems and limitations in it. Many people less convinced about Bitcoin's power and value than I and much more interested in the short term pump are unwilling to tolerate any discussion of challenges; and this creates a poisonous atmosphere which undermines the system's ability to heal and improve.

And today we are left at a point where the bandwidth consumption of an ordinary Bitcoin node just barely fits within the 350GB/mo transfer cap of a high end, "best available in most of the US" broadband service. We cannot know to what degree the load increase was causative, but none of the metrics had positive outcomes; and this is a reason to proceed only with the greatest care and consideration. Especially against a backdrop where Bitcoin's fundamental utility as a money are being attacked by efforts to regulate people's ability to transact and to blacklist coins; efforts that critically depend on the existence of centralized choke-points which scale beyond the system's scalability necessarily creates.

You're right though that the question is substantially political: A fully centralized system could easily handle gigabyte blocks with the work we've do to make megabyte blocks barely viable in a highly decentralized world. Such a system could also happily institute excess inflation, censor transactions, and other moves "for the good of the system" and "to assure widest adoption". If Bitcoin is to survive in the long run we just stand by the principles we believe in, and which make the system valuable in the first place. -- Even against substantial coercive pressure.  Otherwise the transparent system of autonomously enforced rules risks devolving into another politically controlled trust-based instrument of expedience that we see with legacy monetary instruments.

Quote
Furthermore when blocks do fill up we now already have child pays for parent for unsticking transactions without the negative consequences
We do not. CPFP has substantial complexities that prevent it from actually working on the network today; and using it has large overheads. It will be a good additional tool to have, but it does not replace RBF.

Quote
In regards to you saying that Gavin is not active in development I certainly do have a different perspective, considering
You can have a different perspective; but you cannot have your own facts. This is a question of objective fact. But you mistake my comment for an insult, it wasn't intended as one-- who am I to judge what someone else spends their time on? But rather an observation the it would have been surprising to see a contribution there.

Quote
which can only be done significantly by increasing the blocksize.
An action which you could only contemplate due to the work of myself and others who believe that the BIP101 approach would be significantly damaging. I think it's likely that it will be increased in the future, but in a way only that preserves Bitcoin's properties as a decenteralized P2P electronic cash, rather than disregarding them or undermining them.
489  Bitcoin / Bitcoin Discussion / Re: Bitcoin XT - Officially #REKT (also goes for BIP101 fraud) on: November 30, 2015, 05:12:49 PM
When there are technical experts stating opposing things it is hard for people like me to know what is true, Mike and Gavin certainly do think that it does reduce the functionality of zero confirmation transactions.
Mike and Gavin have not commented on Opt-in RBF as far as I am aware; you are confusing his comments on full RBF. But on what basis do you believe their expertise is greater than a dozen other parties?

Opt-in RBF is explained in some detail in the FAQ on Reddit, linked previously to you in this thread; you say that you are open to other views, but you seem to have made no effort to familiarize yourself with them.

That is peculiar considering that he has spoken out against it on twitter, I was not aware that he had not told the Core team about his concerns, I find that a bit strange, maybe you have a better insight on why this is the case. I am going to ask Gavin myself why he did not speak out against RBF when it was being implemented into Core, since I do find that rather strange.
I just checked his twitter feed and can find no comment on it in the last several months. As far as insight, Gavin is not very active in Bitcoin development and hasn't been for a significant time, before the recent blocksize drama. That he didn't comment on the PR was unsurprising on that basis, but he certainly was aware of it-- since he asked when the merge was being discussed in the weekly meeting if we'd talked to any other wallet vendors about it (though this also indicated he hadn't recently read the PR).
490  Bitcoin / Bitcoin Discussion / Re: Bitcoin XT - Officially #REKT (also goes for BIP101 fraud) on: November 30, 2015, 11:10:01 AM
It reduces the functionality of zero confirmation transactions.
No it doesn't.

Quote
If I am a merchant should I reject RBF?
You should wait for confirmation if your risk model says you should. This is already the case, and many properties of a transaction (like low fee or spending unconfirmed inputs) will make most zero conf accepters wait (and still they frequently get ripped off; because the Bitcoin system itself does not provide security for unconfirmed transactions). Fortunately, Opt-In RBF at least means that there is no risk that the confirmation needs to take an excruciatingly long time.

Quote
Even Gavin Andresen is against RBF and last time I checked he was still a Core developer, so now you do not even have your all important "developer consensus".
If he is, he failed to speak up. Of the 19 people that commented on the PR in the nearly two months that it was open, none said anything negative.
491  Bitcoin / Development & Technical Discussion / Re: CoinSwap: Transaction graph disjoint trustless trading on: November 30, 2015, 09:23:43 AM
There are no funds at that 'location'.  No funds are ever sent the revealed key P, funds are sent the the key P+Recipient_Pubkey, which only the recipient knows the private key for (and only after the private key for P is revealed).
 
492  Bitcoin / Bitcoin Discussion / Re: Bitcoin XT - Officially #REKT (also goes for BIP101 fraud) on: November 29, 2015, 01:47:46 AM
The modern large miners are mostly not pools in the historic sense. They own most of their own or at least physically control most of hashpower (directly or through other companies with common ownership). Even to the extent that they are still 'pools', we've seen from experience that the participants have no influence-- e.g. Ghash.io used ~30% hashpower to perform a million dollar scale finney attack, and for months after their hashrate grew, ultimately reaching to 50%. Rather than moving their miners away, people criticized the victim for accepting unconfirmed transactions and moved their hashpower _to_ ghash.


Back to the "LULZ", the desperate attacks on Opt-in RBF (seems that some think they can use this easily misunderstood bit of technology as a proxy in their epic war On Bitcoin Core) have become so shark-jumping-crazy that they're chuckle worthy now: https://www.reddit.com/r/btc/comments/3ukc52/rbf_is_agaisnt_satoshis_vision_peter_todd_and/cxg8wj5?context=3
493  Bitcoin / Bitcoin Discussion / Re: Bitcoin XT - Officially #REKT (also goes for BIP101 fraud) on: November 28, 2015, 01:52:11 PM
If hypothetically more then seventy five percent of the miners supported BIP101 after January. Would Core recognize the will of the economic majority and implement BIP101?
You appear to be conflating unlike things here,  the BIP101 threshold is "75%" hashpower, which right now means perhaps two or three people at the moment. Two or three people are not an "economic majority" by any definition.

Quote
If you would implement BIP101 under such conditions you will have my full support. However if you intend to ignore the economic majority and still attempt to push your own agenda while circumventing and undermining the proof of work consensus then I will accuse Core of tyranny and totalitarianism. Which one is it Greg Maxwell, can you answer this question?
Have you stopped beating your wife?

After careful consideration I believe that BIP 101 is a seriously poor proposal, and I doubt the system would survive in an interesting form with that in the long run: but I don't care to try to convince you of that; when it comes down to it I'm uninterested in being involved in any system implementing it, and so I won't be. If the Bitcoin goes along with it-- I'll just work on something else. And it's my own free choice and will to decide what I work on in my time, hopefully you agree? (mimicking your approach:) and if you think you can tell me what I can work on, how I can spend my time, and what thoughts or program I can publish on my own sites I will accuse you of tyranny and totalitarianism. Which one is it, person who feels comfortable throwing rocks while hiding behind a pseudonym, can you answer this question?
494  Bitcoin / Bitcoin Discussion / Re: Bitcoin XT - Officially #REKT (also goes for BIP101 fraud) on: November 28, 2015, 01:39:17 PM
About being short sighted, are you talking about Core devs procrastination two years ago who didn't care about the blocksize limit which led to all this drama that is happening today? THAT was pretty short sighted IMO. No?

You mean writing things like,

Quote
I think it's clear now that actually getting Bitcoin to the fabled seven transactions per second will be a lot of hard work, [...] If things continue on their present path, scalability is really the least of our concerns [...] When I talk to VCs and Bitcoin-related financial institutions (the others don't care of course), scalability doesn't normally come up as an issue. Why should it? We're not even at 1 transaction per second today.

-- oh wait, that's Mike Hearn.

But seriously, the people you're being critical have done tremendous work on making Bitcoin more scalable.

It's a shame you disrespect us so when your has depended on our (free) labor.  We are struggling to keep the system viable at the current load levels; and have done tremendous work to keep it from falling over or falling into total centralization.

No one I know that is working heavily on the technology believes the system can survive significantly increased scale without actually increasing scalability-- so that's what many people working on; rather than twiddling a knob which slashed the node count the time it was soft-increased previously. Doubly so with fungibility being at least as great a short term concern as scale (and a much greater long term one), as wide spread commercial tracking and coin blacklisting are becoming common; and fungibility improvements come with scaling tradeoffs so to the extent that we have extra headroom we may need it to keep Bitcoin a _money_ (on top of the need for resource headroom to survive attacks).
495  Bitcoin / Development & Technical Discussion / Re: CoinSwap: Transaction graph disjoint trustless trading on: November 27, 2015, 05:23:30 PM
I don't think this will work - I was looking into private key reveal schemes in order to try and counteract the problems with double spending in a proof of burn consensus scheme.

The problem is that the payer can simply construct another transaction in which they send the funds of that private key somewhere else, and then use one of the many techniques to make sure this double spending transaction gets confirmed first.
uh. Your response isn't making any sense to me. I think you've misunderstood the protocol, but I am not sure where-- nothing about the above exists to prevent double spending, the transactions are all confirmed before further action is taken. Please reread and if you still hold the same view write out a sequence diagram that shows your attack so I can understand it.
496  Bitcoin / Development & Technical Discussion / Re: CoinSwap: Transaction graph disjoint trustless trading on: November 26, 2015, 06:02:56 AM
Here is a private atomic swap that doesn't need the multiphase "CoinSwap" transform, as I've come to call the generic protocol here that makes smart contracts private by hiding them from the blockchain.


B computes nonce x and  P = xG, P2 = P + H(P)G

B sends P to A

B pays to   if() {Apub+P2 CHECKSIG} else {CLTV Bpub CHECKSIG}

A pays  to   if() {Bpub2 CHECKSIG P2 FORCEDDISCLOSURECHECKSIG} else {CLTV Apub2}

What is a FORCEDDISCLOSURECHECKSIG? it's a signature construct that forces you to sign in such a way as to disclose the private key.

I am aware of two ways to get this construct in unmodified (no disabled opcodes) Bitcoin today.

One of them is: OP_SIZE 57 OP_LESSTHANOREQUAL OP_VERIFY <P> OP_CHECKSIGVERIFY
497  Bitcoin / Bitcoin Discussion / Re: Bitcoin XT - Officially #REKT (also goes for BIP101 fraud) on: November 26, 2015, 12:56:38 AM
That's supposed to tell us what exactly? That under the most optimal technical environment "the network" can substain large blocks?
I'm shocked  Shocked
Actually, no, they've been having huge problems with it; with nodes crashing all over the place and such. Of course: Bitcoin Core nodes on testnet are unaffected: They're just ignoring the XT chain entirely, banning those peers, and continuing on as if they didn't exist.

498  Bitcoin / Development & Technical Discussion / Re: O(1) Block Propagation, IBLT on: November 25, 2015, 07:08:28 AM
Some propose ordering them, but that promotes censorship and centralization.

Ordering is a free parameter, and can be a deterministic function. Other than the topological constrain for spending the order of transactions in a block is completely arbitrary and without effect. Nothing about _ordering_ promotes censorship and centralization.

Synchronization might well punish those with inconsistent policies; but mining centralization prevents brought about by slow propagation prevents their existence completely.

There are ways to mostly eliminate inconsistency costs using more advanced (pre-forwarding schemes).

If a block is mostly ordered as expected, but not quite; then the amount of information needed to transmit the difference is small in any case; there is no need to strongly bind the consensus rules to this.
499  Bitcoin / Development & Technical Discussion / Re: bitcoin-cli listtransactions not working for watch-only address on: November 23, 2015, 02:34:42 AM
You're asking about account "" but you imported the address in account "1GkktBuJ6Pr51WEJe5ZzyNvMYaMDFjwyDk".
500  Bitcoin / Development & Technical Discussion / Re: bitcoin-cli listtransactions not working for watch-only address on: November 22, 2015, 10:41:00 PM
The empty quotes were not optional, the account name field is missing in your example of trying it.
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 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 ... 237 »
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!