Bitcoin Forum
November 14, 2018, 05:53:36 AM *
News: Latest Bitcoin Core release: 0.17.0 [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 ... 239 »
481  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.

Quote
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.
482  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.
483  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.
484  Bitcoin / Development & Technical Discussion / Re: Segwit details? N + 2*numtxids + numvins > N, segwit uses more space than 2MB HF on: March 24, 2016, 05:24:27 PM
People who use undefined versions for their transactions need to accept that there is a risk.
The primary established mechanism for safe softforks is the reserved script NOPs (which will not be relayed or mined by unmodified software today), the secondary one is transaction versions. They are reserved for explicitly this purpose. The reason for this ranking is that version is global to all inputs and outputs in a transaction; which creates unwelcome tying-- one should be able to spend and create mixtures of coins under different rule sets. For changes that happen outside script, however, version is still available for use.

For segwit the primary mechanism will be segwit witness script versions... which are more clear and flexible than the reserved NOPs.

485  Bitcoin / Development & Technical Discussion / Re: Question about SegWit on: March 24, 2016, 05:19:44 PM
Yes but unlikely. This depends on the implementation. The current implementation is that entering an address will result in creating a normal P2PKH output which Bob could spend from. If there is an implementation that a P2WPKH output is created when an address is entered, then it is possible that Alice would, in effect, lose her coins if she used such an implementation.
What you're saying is equivalent to "in theory there could exist some totally busted software that just make up random crap when alice punched in an address, thereby burning the coins"-- this is true, but it's unrelated to segwit. Smiley

The recipients address specifies the scriptPubkey that they must be paid-to in order to be paid.  If you don't pay to what they've specified, you haven't paid a party.  In the OP's example, Bob would have provided an ordinary address-- the same as he provides today, perhaps-- and the payment would work like normal.

How the txin scripts work and txout scripts work are completely orthogonal.  Someone can spend segwit coins and the receiver doesn't care, it doesn't change their operation; beyond the fact that their older client will see the payment as a non-standard transaction so their non-upgraded wallet will not display it until it confirms.
486  Bitcoin / Development & Technical Discussion / Re: A block-size survey on: March 21, 2016, 09:21:57 AM
Something being less subject to defaults in practice is not equivalent to a system in which defaults are not possible.

Lightning is lightning, it isn't anything else; trying to reason about word pattern matching obfuscates understanding rather than enlightens. If what someone disliked about a weeblix system was that it subjected users to flimdar, then it would be pretty misleading to suggest people wouldn't want some feature that made a system more weeblix like if it didn't expose them at all to flimdar, even if it was otherwise weeblix like.   In this case, I don't even think it's fair to say that lightning is "like" netting, as all transactions in it are ordinary bitcoin transactions ready for transmission to the network-- you just save fees by holding off sending them and having opportunities to revise them. More like writing someone a check, then asking them to rip it up and giving them a new one later in the day when you make another transaction with them-- they could settle it at any time, but save bank interactions if they hold off. Netting would be like writing the check at the end of the week. And in Lightning, unlike the check, the risk is eliminated because of Bitcoin magic.

Today the vast-vast majority of transactions exchanging Bitcoin value never show up in the blockchain-- mostly due to systems with significant counterparty risk, indeed. So, some users perform netting on top of Bitcoin to lower their costs and greatly improve their transaction speeds. Is Bitcoin a netting system? No.  Bitcoin is p2p electronic cash, which periodically settles transactions written by users (which may be revised on the fly prior to settlement). Lightning uses the smart contracting system in Bitcoin to allow that ability to revise pre-settlement for transitive flows of funds without a counterparty risk for funds loss, and not just for single hops.

487  Bitcoin / Development & Technical Discussion / Re: A block-size survey on: March 21, 2016, 06:46:09 AM
Lightning is not a netting system, -- as a clear evidence for that netting universally involves counterparty risk of loss and lightning does not. But if you wanted to talk in terms of netting you perhaps should have said that.
488  Bitcoin / Bitcoin Discussion / Re: ToominCoin aka "Bitcoin_Classic" #R3KT on: March 21, 2016, 05:26:42 AM
Conspiracy theorize all you like, even if it were all true it wouldn't excuse making incorrect statements about Classic's plans...
489  Bitcoin / Bitcoin Discussion / Re: ToominCoin aka "Bitcoin_Classic" #R3KT on: March 21, 2016, 04:51:07 AM
Bitcoin Classic is only proposing to increase the blocksize to two megabytes. That is not an exponential increase at all.
This is Bitcoin "Classic"'s proposal:
Quote
Phase 3 (Q3-Q4) [2016] Make the block size limit dynamic.  Use a variation of Stephen Pairís/BitPay proposal. Validation cost of a block must be less than a small multiple of the average cost over the last difficulty adjustment period.
The main developers of classic previously were pushing an effectively unlimited exponentially growing scheme. They generally reject the notion of any blocksize limit at all.
490  Bitcoin / Bitcoin Discussion / Re: What if classic coup is just a large-scale manipulation by altcoin pumper gang? on: March 20, 2016, 11:58:37 PM
giving it a new name does not give it new life
It isn't just a new name, the channels are bidirectional; which radically improves their utility.
491  Bitcoin / Development & Technical Discussion / Re: A block-size survey on: March 20, 2016, 11:29:13 PM
In banking, a settlement system usually is a system to periodically update a coarse-grained ledger with the an aggregate of finer-grained transactions.
Have you been introduced to the concept of "blocks"? (sorry, I really don't intend this to be mocking sounding, but I'm not finding a better way to put it).  What you described is _exactly_ how Bitcoin works.
492  Bitcoin / Bitcoin Discussion / Re: What if classic coup is just a large-scale manipulation by altcoin pumper gang? on: March 20, 2016, 11:26:46 PM
seems no one is denying blockstreams has ties to banks
Huh? I do. What ties to what banks are you talking about?

Quote
seems no one denies that blockstream prefer people not to use real secure bitcoin ledger transactions and instead want people using less distributed less secure LN hubs.
I do. What is a "LN hub"?  If you're talking about lightning, every lightning transaction is a "real bitcoin ledger transaction" just most are hopefully superseded before they hit the blockchain, without degrading their security. If this seems impossible to you should checkout cut-through transactions as a parallel technology that might open your eyes.

In my vision of lightning there isn't much in the way of hubs, but a mesh of users. If I wanted to build a hub I'd build a chaumanian cash bank. Payment channels were originally proposed by Bitcoin's creator, and the Bitcoin transaction format has specific affordances to support them (e.g. sequence numbers).
493  Bitcoin / Development & Technical Discussion / Re: A block-size survey on: March 20, 2016, 05:52:18 PM
I have created a quick survey about the block-size limit and would love to hear your answers:
https://docs.google.com/forms/d/18JfNC21Jo1adTI6YNxiFrw4BXRAbI4LrdWx2hFbWSJY/viewform

Consider the question from the survey:
Quote
In 10 years, Bitcoin will be
a peer-to-peer electronic cash system
a peer-to-peer electronic settlement system
a store of wealth (digital gold)
obsolete

What is "Bitcoin" being referred to there?  Is it referring to the Bitcoin Currency? Or the P2P network? or the blockchain itself? current Bitcoin companies?

What is a "settlement system" which is exclusive with"cash system"?  The definition of a settlement system is a system that delivers money in exchange for the fulfillment of a contract. This is the technical definition of the Bitcoin blockchain. What is a "cash system"?-- The bitcoin currency is cash (although cash with some fungibility problems); if it weren't the blockchain couldn't be a settlement system (since it wouldn't be a system that delivered money for fulfillment of agreements); and none of these two are incompatible with Bitcoin being a store of wealth.

There is a common misunderstanding of what settlement means-- to suggest that its somehow not for personal use, and also suggesting that these options are exclusive. They aren't. And one of them, except "a store of wealth", even speak that strongly to the blocksize:

One could have a "peer-to-peer electronic cash/settlement system" that was highly regulated, censored, and had a politically determined and/or unstable monetary policy. But it's hard to imagine something that would be a good "store of wealth (digital gold)" that wasn't a strongly autonomous and permissionless bearer instrument with a strongly fixed monetary policy (criteria which might implicate the block size in both directions).

Quote
Blocks are like penises: the bigger the better.

Maybe I was expecting too much of the poll.

It certainly seems to have nothing to do with technical discussion.
494  Bitcoin / Development & Technical Discussion / Re: Does SegWit require any change in using send/receive API? on: March 18, 2016, 10:19:26 PM
I am using blockcypher send/receive API in certain services and accept Tx with 1+ confirmations. Post SegWit, do I need any change to be made at my end?
No, only if that API did something weird.

Is the API doing "something weird" predictable?
The prediction is it wouldn't.

I mean, if you're using a third party API then at any point they could make you add an argument "moon moon fish moon"... but there is no reason for them to do that; likewise for segwit.
495  Bitcoin / Development & Technical Discussion / Re: -dbcache not working as intended in core 0.12 (?) on: March 18, 2016, 10:18:13 PM
-dbcache=0 works way faster, betraying some kind of problem in the way caching works.
No, it's way faster because the initial startup tests are truncated when the cache is too small. (Because they undo a bunch of blocks in memory and redo them... they need enough memory to hold that intermediate state)
496  Bitcoin / Development & Technical Discussion / Re: Does SegWit require any change in using send/receive API? on: March 18, 2016, 04:03:32 PM
I am using blockcypher send/receive API in certain services and accept Tx with 1+ confirmations. Post SegWit, do I need any change to be made at my end?
No, only if that API did something weird.
497  Bitcoin / Development & Technical Discussion / Re: Segwit details? SEGWIT WASTES PRECIOUS BLOCKCHAIN SPACE PERMANENTLY on: March 18, 2016, 09:25:16 AM
* Malleability could be fixed by just skipping the signatures (the same data that SegWit would segregate) when computing the txid.  
That _is_ segregation of the signatures up to completely non-normative ordering of data transferred. Segwit could just as well order the data into the same place in the serialized transactions when sending them, but its cleaner to not do so.

Quote
* GREATER bandwidth savings could be obtained by providing API/RPC calls that simple clients can use to fetch the data that they need from full nodes, sans the signatures etc.  This enhancement would not even be a soft fork, and would let simple clients save bandwidth even when fetching legacy (non-SegWit) blocks and transactions.  
This would be no greater and it would have _no_ security at all. The clients would be _utterly_ beholden to the third party randomly selected servers to tell them correct information and they would have no way to verify it.

I normally don't expect people advocating Bitcoin Classic to put security first, but completely tossing it out is a new turn. I guess it's consistent with the latest validation removal changes in classic.

Quote
* Pruning signature data from old transactions can be done the same way.
Has been for years.
498  Bitcoin / Development & Technical Discussion / Re: Segwit details? SEGWIT WASTES PRECIOUS BLOCKCHAIN SPACE PERMANENTLY on: March 18, 2016, 09:21:30 AM
So far I haven't seen this desirability in itself argued,
Please read the fine thread here.
499  Bitcoin / Development & Technical Discussion / Re: Segwit details? SEGWIT WASTES PRECIOUS BLOCKCHAIN SPACE PERMANENTLY on: March 17, 2016, 05:53:37 AM
This is a networked society, I don't think a hard fork is that difficult as you said. Ethereum just had one and no one complains
You're getting caught up on terms, thinking that all hard forks are the same. They aren't.  Replacing the entire Bitcoin system with Ethereum would, complete with the infinite inflation schedule of ethereum would just be a hardfork. ... but uhhh.. it's not the same thing as, say, increasing the Bitcoin Blocksize, which is not the same as allowing coinbase txn to spend coinbase outputs...

Quote
Just like a soft fork, you have a long period to inform all the users to upgrade, those who don't care, their software will just not be able to talk to the network and the transactions will be dropped.
That isn't like a soft fork, soft forks don't kick anyone out of the network. And you seem to have missed what I said, because of nlocked transactions changing the transaction format would effectively confiscate some people's Bitcoins.

Quote
When a large bank upgrading their system, all the users of that bank can not access the banking service for at least hours or whole night/weekend, no one complains.
Yes, Banks are centralized systems-- ones which usually only serve certain geographies and aren't operational 24/7. Upgrading them is a radically different proposition than a decentralization system.  A Bitcoin hard fork is a lot more like switching from English to Metric system, except worse, because no one values measurement systems based on how immune to political influence they are.

Iím aware that Core is focused on encouraging a gradation of nodes on the network. To me, a full node means a full, archival, fully validating node, and thatís what Iím
Your usage of the word full node is inconsistent with the Bitcoin communities since something like 2010 at least. A pruned node is a full node. You can invent new words if you like, but keep in mind the purpose of words is to communicate, and so when you make up new meanings just to argue that you're right, you are just wasting time.

You claim to be concerned with validating, but I do not see you complaining that classic has functionality so that miners will skip validation: https://www.reddit.com/r/Bitcoin/comments/4apl97/gavins_head_first_mining_thoughts/

Quote
SoÖ changing these incentives was _the_ ray of light that allowed ďlots of peopleĒ (assuming blockstream here) that a capacity increase could be had, fascinating. Before your email became the core roadmap, and before the conclusion of the HK conference, almost everyone thought that we would be hard forking at least some block size increase. Interesting to hear that perspective was wrong all along.
No, not blockstream people (go look for proposals from Blockstream people-- there are several blocksize hardforks suggested). Because of the constant toxic abuse, most of us have backed away from Bitcoin Core involvement in any case.

Quote
Not surprising, segwit was designed with the "side" benefit of making sig heavy settlement tx cheaper, and a main benefit of fixing malleability which LN requires.
Fixing this is a low enough priority that we canceled work on BIP62 before soft-fork segwit was invented. In spite of this considerable factual evidence, you're going to believe what you want, please don't waste my time like this again:

Quote
(2) Lightning HTLC transactions have tiny signatures, and benefit less than many transaction styles (in other words the recosting should slightly increase their relative costs), though no one should care because channel closures are relatively rare. Transactions that do large multisigs would benefit more, because the current size model radically over-costs them relative to their total cost to Bitcoin nodes.

Waves hands.

luke-jr told me it takes 2 bytes per tx and 1 byte per vin extra using segwit as opposed to a 2MB hardfork. I thought you also confirmed this. Now you are saying that using segwit reduces the total permanent space used by 30%, if that is really the case then I will change my view.

please explain to me how lukejr is wrong when he says it takes 2 bytes per tx and 1 byte per vin. i will update the title to match my understanding, without shame when I see my mistake. Imagine I am like rainman. I just care about the numbers
Luke told you what the Bitcoin Core segwitness implementation stores. For ease of implementation it stores the flags that way. Any implementation could do something more efficient to save the tiny amount of additional space there, Core probably won't bother-- not worth the engineering effort because it's a tiny amount.

Part of what segwitness does is facilitate signature system upgrades. One of the proposed upgrades now saves an average of 30% on current usage patterns-- I linked it in an earlier response. It would save more if users did whole block coinjoins. The required infrastructure to do that is exactly the same as coinjoin (because it is a coinjoin), with a two round trip signature-- but the asymptotic gain is only a bit over 41%.  It'll be nice for coinjoins to have lower marginal fees than non-coinjoins; but given the modest improvement possible over current usage, it isn't particularly important to have whole block joins with that scheme; existing usage gets most of the gains.
500  Bitcoin / Development & Technical Discussion / Re: LevelDB reliability? on: March 17, 2016, 05:38:38 AM
That's precisely what we did with Monero. We abstracted our blockchain access subsystem out into a generic blockchainDB class,
Thats exactly how core has been done for years.

Though we don't consider it acceptable to have 32bit and 64 bit hosts fork with respect to each other, and so prefer to not take risks there!
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 ... 239 »
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!