Bitcoin Forum
January 23, 2019, 04:38:01 AM *
News: Latest Bitcoin Core release: 0.17.1 [Torrent]
  Home Help Search Login Register More  
  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 76 ... 241 »
501  Bitcoin / Alternative clients / Re: Bitcoin core for android? on: April 17, 2016, 11:37:44 PM
There is an android version, ABCore:

The low processor performance of most android devices combined with the phenomenal growth of the blockchain really reduce it's utility, however.

502  Bitcoin / Development & Technical Discussion / Re: Bitcoin Core Paper Wallet on: April 14, 2016, 06:46:00 AM
Who the do you think _invented_ BIP32?    Huh
503  Bitcoin / Development & Technical Discussion / Re: SegWit and SPV-mining. What if...? on: April 14, 2016, 06:38:35 AM
Tomorrow they would say: "Sorry, man. Your client just doesn't have segwit-data. We also can not provide it to you, but we are sure that it exists somewhere so we will not reorganize the main chain."
Pedantically, that isn't how the protocol works. You cannot transfer the block without segwit data to supporting full node systems. Older systems don't get it, but it doesn't matter if they get it or not as they wouldn't enforce any rules with it. I think your question is actually about old systems, in which case the transmission part is a distraction.

The segwit data is not sent separately.
Why? One can send block to the network to all nodes 0.12.x, 0.11.x etc, wait 30 seconds, and send the segwit data
Old software indeed doesn't necessarily verify all the rules that are at play: this is unavoidable, since you cannot even know potentially all the rules that are at play as miners could be enforcing ones no one but they know about. The same holds for any rule addition, like P2SH, or CLTV, or CSV.

At least for intentional public rule additions, the process limits exposure:  In the BIP9 protocol no new rules are added until two weeks after 95% of hashpower signals an intent to enforce. During that time and before full node software will have been producing loud warnings: "Warning: Unknown block versions being mined! It's possible unknown rules are in effect", "unknown new rules are about to activate", and "Warning: unknown new rules activated", notices for a month-- allowing parties to upgrade or connect their node via another upgraded node (that filters the blocks they receive). The process also is date gated to give time for upgrades even before it potentially begins. No non-upgraded full node software will create addresses using the new rules (nor would any prudent wallet generate them until they're widely enforced in the network) nor accept unconfirmed transactions that use them as they're non-standard. One could set their wallet to automatically delay or withhold action when a new rule they haven't been updated for has gone into effect, until upgraded or manually bypassed for that particular new rule, but for virtually any application that would be excessive-- considering that 95% of hashpower are updated to enforce and a process which results in wide deployment of node software.

(As an aside, segwit would be in 0.12.2/0.12.3; and potentially 0.11.x too though it looks like there isn't demand for it)
504  Bitcoin / Development & Technical Discussion / Re: <<How Software Gets Bloated: From Telephony to Bitcoin>> on: April 14, 2016, 06:12:33 AM
Is not placing the Merkle root for the block's witness data in a transaction rather than in the block's header, not a quintessential example of a "kludge" or a "hack"?
The block header would emphatically _not_ be the right place to put it. Increasing the header size would drive up costs for applications of the system, including ones which do not need the witness data. No one proposing a hardfork is proposing header changes either, so even if was-- thats a false comparison. (But I wish you luck in a campaign to consign much of the existing hardware to the scrap heap, if you'd like to try!)

What about the accounting trick needed to permit more bytes of transactional data per block without a hard-forking change?  This hack doesn't just add technical debt, it adversely affects the economics of the system itself.
Fixing the _incorrect costing_ of limiting based on a particular serialization's size-- one which ignores the fact that signatures are immediately prunable while UTXO are perpetual state which is far more costly to the system-- was an intentional and mandatory part of the design. Prior to segwit the discussion coming out of Montreal was that some larger sizes could potentially be safe, if there were a way to do so without worsening the UTXO bloat problem.

In a totally new system that costing would likely have been done slightly differently, e.g. also reducing the cost of the vin txid and indexes relative the txouts; but it's unclear that this would have been materially better; and whatever it was would likely have been considerably more complex (look at the complex table of costs in the ethereum greenfield system), likely with little benefit.

Again we also find that your technical understanding is lacking. No "discount" is required to get a capacity increase. It could have been constructed as two linear constraints: a 1MB limit on the non-witness data, and a 2MB limit on the composite. Multiple constraints are less desirable, because the multiple dimensions potentially makes cost calculation depend on the mixture of demands; but would be perfectly functional, the discounting itself is not driven by anything related to capacity; but instead is just a better approximation of the system's long term operating costs. By better accounting for the operating costs the amount of headroom needed for safety is reduced.
505  Bitcoin / Development & Technical Discussion / Re: SegWit and SPV-mining. What if...? on: April 13, 2016, 07:52:18 PM
Is the following scenario valid?

1. Some unhonest segwit mining pool takes top-1000 segwit utxo and mines a block at height N with a transaction which transfers all funds to his p2pkh address
2. This block does not have segwit data portion, but it can be broadcasted to all non-segwit nodes on the network
3. All other pools have a dilema - wait the segwit data associated with this block or start mining block N+1 on the top of N
4. What if miners will use SPV-mining on the top of this block? They will create blocks at heights N+1, N+2... etc without checking the segwit-validity of block N

No different than the situation today with "spend all the coins in the first 10000 blocks, without knowing the private key; and hope that miners extend the chain without having or checking the block. The segwit data is not sent separately.

In either case the corrupt chain would be simply reorged out after miners hit their limit of mining without data or otherwise some process realizes they are mining a chain the network is rejecting. Non-validating clients would be exposed to the reorganization, ones that are validating would not be.
506  Bitcoin / Bitcoin Discussion / Re: ToominCoin aka "Bitcoin_Classic" #R3KT on: April 13, 2016, 05:57:54 PM
I don't think it was specifically stated (yet?) that it would be at 95%. People only assume this as it was used in the past.
Thats how BIP9 works right now. Perhaps experience with the first BIP9 deployments (CSV/etc.) will cause the spec to be changed, but for now it's reasonable to assume that it won't be.

(There is a lot more to the trigger threshold than just "95%"-- BIP9 gets rid of the rolling measurement so the 95% from BIP9 is a much higher bar than the 95% from the rolling method used in the past; the network has never used a bar this high for a soft-fork deployment before, so we may learn some things during the roll of of the first features with it.)
507  Bitcoin / Development & Technical Discussion / Re: <<How Software Gets Bloated: From Telephony to Bitcoin>> on: April 10, 2016, 07:09:50 PM
He glosses over the important part in order to make an extremely tenuous inference;
"Most of my brain feels that this is a brilliant trick, except my deja-vu neurons are screaming with 'this is the exact same repurposing trick as in the phone switch.' It's just across software versions in a distributed system, as opposed to different layers in a single OS."
Bolded for emphasis.

That is not "just" a minor difference that can be hand-waved. That is the raison détre of the soft fork. It is not because Bitcoin developers are concerned that they might mess something up, or that it would be a lot more work to do a hard fork, which seems to be the implication in this article.

It also ignores, or isn't aware, of the fact that we implemented segwit in the "green-field" form (with no constraint on history), in Elements Alpha-- and consider the form proposed for Bitcoin superior and are changing future elements test chains to use it.

Applying this to Bitcoin conflates misleading source code with protocol design. None of these soft fork things result in things like mislabeled fields in an implementation or other similar technical debt-- if that happens it's purely the fault of the implementation.

508  Bitcoin / Bitcoin Discussion / Re: /btc is full of hypocrites or shills on: April 06, 2016, 07:33:24 PM
Since when has malleability had _anything_ to do with the (in)security of accepting unconfirmed payments? 0_o
509  Bitcoin / Bitcoin Discussion / Re: Clearing the FUD around segwit on: April 05, 2016, 09:02:11 AM
You sounds like a central planner/protector for all the people. This is experimental software and open source isn't it, no one is responsible for people's financial loss, thus everyone here knows how to protect themselves by only investing risk money. But they hate being centrally controlled, it seems you value money over freedom
If third parties make decisions to take away your funds, then Bitcoin isn't money. I find it amusing that you call avoiding that, "centrally controlled".

hm - you can improve, debug and grow only with constructive critics, so I  wonder (but could understand as well)  that you lose patience here ...
You are a sience guy, so you know your theory fail once you cannot convince your critisizers .
There is little point in arguing with a climate change denier or creationist whos positions are axioms and not based on the science. At some point all there is left to say is that this is what Bitcoin is, it's what it's been since the start-- the poster has already aggressively and insultingly disregarded the advice of virtually everyone with established expertise-- and promotes a vision, things like it being okay to make changes that confiscate people's funds, that in my opinion is practically and ethically incompatible with Bitcoin. I feel no shame in telling such a person that Bitcoin may not be what they seek.

If Bitcoin is to satisfy anyone it cannot satisfy _everyone_; some demands are mutually exclusive.

old clients wont check whats after 0x00(op_0).. they automatically treat the transaction as valid.
This is the property of the address, not the signature; if it were a property of the signature you could already simply steal any coin.
510  Bitcoin / Bitcoin Discussion / Re: Clearing the FUD around segwit on: April 05, 2016, 07:14:48 AM
You really don't need all these wasted efforts of patch making and testing if you just do a hard fork
That would be strictly harder not easier. The older behavior must be accommodated regardless or it will confiscate peoples coins.

I'm sorry you disagree with the method used by Bitcoin's creator-- as well as almost every technical expert to come after-- has fixed and maintained the system, perhaps you should use something else.
511  Bitcoin / Bitcoin Discussion / Re: Clearing the FUD around segwit on: April 04, 2016, 09:30:56 PM
Thanks & yes, I got that. But this soft fork happens at 4) or two weeks later.
The question is, whether the new coded miners (SW enabled) will orphane the non SW chain down two that BAD block made in 2)  because they will all agree that this BAD but old block is the last valid SW one since it contains the correct LAST  correct SW  entry?
No, that block will not be invalid. The rule is not enforced for any blocks before the specific block where the activation starts, all at once for everyone upgraded (including the 95%+ hashpower that triggered it). The blockchain itself assures that the triggering is coordinated and that almost all the hashpower is running software that can enforce at that coordinated point.
512  Bitcoin / Bitcoin Discussion / Re: ToominCoin aka "Bitcoin_Classic" #R3KT on: April 04, 2016, 04:21:41 PM
Gmaxwell R3KT - this criticism below seems reasonable and implies you have no clue how in PGP windows works, how about explaining this?
That document is a thoroughly confused rant written by some fraudster.

What the "paper" is pointing out is that although the hash preference list or "8 2 9 10 11" and the other metadata were not conceived of or implemented until a year after the claimed date (as I pointed out); it was possible, by a long series of complex manual commands to manually override the preferences and punch in whatever ones you wanted, even the 'future' ones.

You may note that it take great care to provide no citation to my actual comments, in fact it quotes me but uses an image for the text-- making it more difficult to even search for it. Allow me:

"The suspect keys claim to be October 2008; the commit was July 2009. So no, not without a time machine. It's possible that the settings could have been locally overridden to coincidentally the same defaults as now."

-- so the whole theory that this "paper" writes for pages and pages as if it were some great concealment on my part is a possibility I explicitly pointed out.

The problem with it is that it requires the user to have executed a long series of complex commands to override the preferences and have to have guessed the exact selection and ordering of the preferences that wouldn't be written for a year-- when if they preferred a particular cypher they would more likely have taken the existing "2 8 3" and stuck their choice on the front.  Not only that, but they would have had to have done so on the same day that they created a totally ordinary key and published it, yet this other key-- which looks exactly like one created with post-2009 software and entirely unlike the well known one-- was provided to no one for years, not placed on public key servers and until now and otherwise has no evidence of its prior existence. Come on, give me a break.

It's "possible", a fact a pointed out explicitly back then, but this possibility thoroughly fails Occam's razor-- especially on top of the evidence presented by others: showed the subtle "hint dropping" added in blog entries was back-dated, added in 2013, SGI reported that the published letter on their letterhead was fake, the lack of cogent technical commentary from that party, etc.

Bringing it back on topic, I'd say that it's surprising that all these Bitcoin Classic folks believe such tripe, but in the context of all the other incompetent nonsense they believe, it doesn't seem so surprising.
513  Bitcoin / Bitcoin Discussion / Re: Clearing the FUD around segwit on: April 04, 2016, 03:55:17 PM
Just to summ up / that attack would be like that:
A miner
1) modifies his own mining code to enter  already the SW link into the correct place
2) mines a BAD block NOW, Long time before SW goes live
3) Now he can do lots of real txs like spending BTC (but get back when)
4) SW goes live and all blocks down to his BAD block get orphaned and his spending from 3) are neglegted
? correct ?
Soft-forks are not enforced on the older parts of the chain. Only in blocks from two weeks after 95% of the hash-power had signaled their intent to enforce (counted over a 2016 block interval after the change start-time).

For prior soft-forks, like strictder, there are many historical violations before where it was enforced. It does not make the chain invalid, only violations after the point where the new rule's enforcement begins would do so.
514  Bitcoin / Development & Technical Discussion / Re: understanding the second layer on: April 03, 2016, 08:42:45 AM
Has anybody done any kind of analysis of what percentage of transactions are the type of recurring transaction which could use Lightning Network?
"100%" of them. The above posts are confusing old single party unidirectional payment channels; more powerful designs have been known for something like 5 years, the most sophisticated with are the bidirectional payment mesh systems we call lightning today. No reoccurring usage is required to make use of them, though they're super efficient for that case.

John Ratcliff wrote a nice informal discussion about what bidirectional payment channel networks are:

515  Bitcoin / Bitcoin Discussion / Re: ToominCoin aka "Bitcoin_Classic" #R3KT on: April 01, 2016, 07:08:11 AM
if a miner minted a block today that had 1 segwit-like TX in it, i seriously doubt that block would be valid.
It would be valid, of course. Perhaps you should consider posting less and studying more? -- not trying to insult, but without the basics you're wasting people's time.
516  Bitcoin / Bitcoin Discussion / Re: Core have been derelict in their duties. on: March 29, 2016, 09:48:04 PM
Blocks are always full. When they're not a million bytes, they're less because a miner chose to limit the capacity further, but to whatever capacity they were allowed they're full. There are spam generators that generate a constant flood of minimal fee-rate transactions constantly 24/7... a node with all anti-spam defeated and no mempool limit quickly ends up with hundreds of megabytes of transactions.

This isn't a problem, it's how the system works... and it is unavoidable in a decentralized system ---  imagine instead that there were no limits at all (not in the consensus rules, not by miner collusion)-- that would be the necessary criteria for blocks to not be "full" and in that world a single kid with a while loop could throw hundreds of gigabytes of data into blocks and rapidly DOS the whole system into the ground.

When you get fed hype around "full" blocks, you're being fed a fake emergency narrative.
517  Bitcoin / Development & Technical Discussion / Re: is it possible to send zero bitcoins on: March 29, 2016, 07:28:25 PM
I understand now, if bitcoin core doesn't think zero bitcoin transaction as spam, then we would have 1000's of spam transactions. Can't imagine how the blockchain would be. We may need terra bytes of harddisk.
The blocksize limit protects against that, but it's preferable to use the least amount possible, since even the limit is high enough to make running nodes burdensome; better to spend user's limited tolerance on actual Bitcoin transactions.
518  Bitcoin / Bitcoin Discussion / Re: ToominCoin aka "Bitcoin_Classic" #R3KT on: March 29, 2016, 04:38:55 PM
75% isn't even close to it.
Especially when you realize that people connected to classic are demanding not "75% of users" or "75% of bitcoin ownership" but 75% hashpower, the last of which could just be a couple people.

Softfork is also 75% trigger condition
That isn't true. A long time ago they were done with hashrate thresholds that low and it was problematic. More recent ones have been 95% hashrate.

and the new segwit softfork method demonstrated that you can change anything (including 21m coin supply)
That is also not true. You could create some kind of colored coin and try to convince people to accept it as "bitcoin" even without any soft-fork, but no soft-fork can increase the supply of actual Bitcoins.
519  Bitcoin / Development & Technical Discussion / Re: is it possible to send zero bitcoins on: March 29, 2016, 04:12:02 PM
The Bitcoin consensus protocol allows creating and sending transactions involving no bitcoins what-so-ever.

Bitcoin Core currently regards such transactions as spam and will not relay them.

This is the basis by which proponents of various parasitic consensus systems (their term not mine) have argued that their new currency would completely displace Bitcoin even while using the Bitcoin network.
520  Bitcoin / Development & Technical Discussion / Re: Segwit details? N + 2*numtxids + numvins > N, segwit uses more space than 2MB HF on: March 26, 2016, 07:35:19 AM
The primary established mechanism for safe softforks is the reserved script NOPs (which will not be relayed or mined by unmodified software today)
If a fork makes a previously illegal opcode legal, how can it be a soft fork?
I would encourage you to read what I actually write. I said nothing of illegal opcodes, and for good reason.
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 76 ... 241 » is not available or authorized for sale. Do not believe any fake listings.
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!