im still laughing at people who "love" core/blockstream

saying how they are
ok with bloating a 2-in2-out tx upto a few kilobytes purely to make the transaction TEMPORARILY confidential. but PERMANENTLY bloated.
ok with having tx's locked into 3-5 day maturities (CLTV frozen funds)
ok with chargebacks (CSV revoke codes)
ok with permissioned 2 party authorised transactions (LN)
ok with third party management (LN outsourced management)
ok with fee penalties

and ill say it again ok with bloating each transaction that was ~400byte to become over 1kb.

but if anyone ever hints that core Devs should lose their grip of spoonfeeding the code... everyone goes insane

the funny thing is that the core sheeple think that segwit is a boost from ~2500tx to 4500tx.. yet thats if everyone, yes everyone uses segwit.
but by the time everyone made the switch. confidential payments would be bloating things up again causing the transaction count per block to decrease while the size per transaction increases.

constellation..??

at first i thought why is the OP and the article using that word.
then i thought. what words have we used in the past..

hmm.. 'community' sounds more like a small neighbourhood, village or a cult. a small mens club.
hmm.. 'eco-system' sounds more about plant ecology buzzword rather than the economic system it suppose to be a buzzword for.
hmm.. 'arena' sounds like a entertainment/fightclub venue
hmm.. 'sanctum' but thats again a private boys club sounding buzzword

but i still think that constellation, just doesnt sound to be the right buzzword for describing bitcoins infrastructure and industry.

i personally prefer bitcoin industry when talking in the context of the article

you can always spot the blockstream sheep

they want to avoid onchain scaling.
they think offchain is the only way.
they love the idea of a fee war onchain
they love bloating onchain transactions by kilobytes via confidential payment commitments

a simple rule that would avoid mining centralization would be that no pool can submit a block hash solution if it has already solved 2 out of the last 6 blocks. that way a pool will never get more than 33% control, they would automatically get rejected at the 3rd attempt within the last 6 blocks.

seems like a simple rule that solves the 51% attack worry right??

though that can be worked around by a pool running 20 pools and quickly pool hops as soon as it solved 2 blocks.
so for every problem there would be a work around, found.

the problem is not that one pool hits 51% to do something. its the extra fact that a couple separate pools can agree to do something if their manage to control a majority of the blocks that are being solved.

and no matter what solution you find. someone else WILL find a work around. or a way to twist the rule in their favour EG if a rule is created to reject a block if the submitter is submitting too many. that same rule can be abused to deny independence , much like gmaxwell proposes to intentionally reject blocks if they do not collude with core

might be worth you doing some fact checking.

its core that wants to handcuff bitcoin to turn everyone over to LN (paypal2.0). yet those opposing bitcoin want more real permissionless transaction on the mainnet.

its core that while handcuffing bitcoin, they want to bloat transactions with kilobytes of data (confidential payments) where the reality is that these confidential payments will only be confidential for a few days before the 'hidden value' is revealed.

its core that want certain LN (paypal2.0) hub managers having a masterkey to move peoples funds without their consent to use to mix other peoples funds with only a moral judgement that these masterkey holders would put funds back.

thus LN/mimble wont be permissionless, trustless, or even frictionless. those making LN are already putting in stumbling blocks and penalties to charge people extra just for the 'privelidge' of using LN. after all their desire is to repay blockstreams investors so they need to handcuff bitcoin to force people into LN(paypal2.0) to get those penalty fee's to hand back to blockstreams banker investors.

it really makes me laugh pretending blockstream are not involved with the banks..

its not genius..
its a path to centralization and middlemen taking your funds(hoping they put it back). same with CLTV locking you out of your own funds until they mature and CSV revoking the funds way from you like chargebacks. turning features into things banks do.... things we should be avoiding, not welcoming.

do you honestly think that wasting over a kilobyte per tx to hide a transactions true value which within weeks can become obsolete once analysts get the commitment.. thus bloating the blockchain up for nothing.

yes features sound good at concept. but when running them through real world scenarios and see what actually happens when used, and used repeatedly.. these features fall flat of any permanent solution/utility. but the risks of malicious use to steal funds or bloat the chain become apparent

i dont see these features as "genius". yes they are original and new.. but not a proper solution to the problem

funny thing is its the blockstream paid devs that are wanting centralization. mainly to push bitcoin down a rabbit hole to commercialise it and repay their investors.

Gmaxwell proposed anyone not core should ForK off


gmaxwell proposed auto rejecting blocks simply because those blocks dont vote for core

kind of funny how gmaxwell wants to cause an intentional split just to activate a soft fork.. very counter intuitive

as also shown above, gmaxwell is so desperate and depraved he calls anything not core an altcoin... makes me laugh that he stoops that low to confuse his sheep

it is actually the blockstream paid devs and their interns that have been on a campaign to centralize the blockchain, telling lies, twisting the truth and spreading rumours to try reigning their sheep into the wolfs den

as for the impending replies of the sheep.. distribution vs decentralization are two very different things.
yes bitcoin is distributed. but if they are all blindly following the wishes of just a few devs.. then distribution becomes meaningless because independence is lost

currently multisigs will delay time because the front end currently take a long time. due to having to manually build a transaction.
bt if the devs (im not relying on core dvs because they dont care about such things) othre devs will make userfriendly front ends that make it simplistic and easy as typing in an amount and pressing send.
thus a milisecond thing. not a minute thing.

imagine it.
you have a multisig with an exchange. the LN node is api calling the exchange as a hub, to send the signed tx's
along with signed TX the LN node can obviously API call other data to the exchange.
so imagine your LN node is the exchange 'bot' thus not needing to log into an exchange webpage separately but all done within an LN node

its got nothing to do with the price of bitcoin.

the 10 minute theory is not a hard rule

the hard rule is 2016 blocks in 2 weeks..
this could be 2015 blocks in 2 hours and then 1 block taking 1 week, 22hours
this could be 1008 blocks in 1 day hours and then 1008 block taking 1 week, 5day 23hours, 50 minutes

where in both cases no difficulty adjustment is needed.
or it could be only 1995 blocks are found in the next 2 weeks. causing the difficulty to drop to compensate
or it could be only 2036 blocks are found in the next 2 weeks. causing the difficulty to rise to compensate

the reason most blocks are found in ~10 minutes is when hashrate is exceeding difficulty that more often than not blocks are found quit rapidly.

on the 28th of december the difficulty jumped by 2% (310-317) but the hashrate has not grown by 2%.
the hashrate was at 2,575 and is now 2,337 (-1%) meaning the solution is 2% harder but the hashrate is 1% less.. causing a 3% drop in efficiency.

this wont correlate exactly to a 3% change in timing. but more so a 3% more of a chance that some blocks will take longer than usual.
EG imagine there were 2016 blocks measured at ~10minutes

it could mean
60 blocks taking a little longer than usual(11min instead of 10mins)
6 blocks taking alot longer than usual(an hour instead of 10mins)
1 block taking even lonnger than usual (6 hours instead of 10mins)

the first one is most likely. the last one is least likely. but no one can know with exactly honestly when the next block will be solved to the exact second.

its only average 10minutes based on the maths of 2 weeks

firstly you have to understand the concepts of multisig. where not only is it a 2 of 2 but there is an ability of a masterkey that can override both.

next you have to understand confidential payments where the units of measure are replaced with randomlooking number that a commitment of a few kilobytes of data added to the tx can translate, but only by keyholders.

next you have to understand that mimble is where a masterkey holder of many unspent multisigs can move the funds with the cough promise cough that everyone is made whole eventually, but by moving funds from different multisigs at different times and by the funds being non-transparant. blockchain analysts wont be able to know who paid what to you and how much and when. because the masterkey holder is grabbing random unspents to hide the true payments so analysts cant tell whats a true payment and what is just a ruse.

---

firstly confidential payments
imagine a multisig address is created between bob, alice and fred.. bob and alice are the 2-of-2 and fred is the manager with a masterkey
the multisig is 3bobalicefred

imagine the blockchain sees:
[in: 1bob value=20546590.90909091]
[out: 3bobalicefred value=20546590.90909091]
signed bob
commitment: bcd2b8e028b1d215bb3cb3a9a693d023c4cb906820ba423be1282590eb41bdc9

[in: 1alice value=33409090.90909091]
[out: 3bobalicefred value=33409090.90909091]
signed alice
commitment: bcd2b8e028b1d215bb3cb3a9a693d023c4cb906820ba423be1282590eb41bdc9

above is just bob and alice funding the multisig
now fred moves the funds to another multisig
[in: 3bobalicefred value=20546590.90909091]
[in: 3bobalicefred value=33409090.90909091]
[out: 3fredmultisig value=53955681.81818182]
signed fred
commitment: bcd2b8e028b1d215bb3cb3a9a693d023c4cb906820ba423be1282590eb41bdc9

in my example commitment each satoshi is multiplied by 294 then divided by 176 but the blockchain is not told that its 'multiply 294 divide 176'
only bob, alice and fred know about ''multiply 294 divide 176''
this is what fred alice and bob see
[in: 1bob value=0.123btc]
[out: 3bobalicefred value=0.123btc]
signed bob

[in: 1bob value=0.2btc]
[out: 3bobalicefred value=0.2btc]
signed alice

[in: 3bobalicefred value=0.123btc]
[in: 3bobalicefred value=0.2btc]
[out: 3fredmultisig value=0.323btc]
signed fred


on the face of it blockchain analysts dont know what the hell
20546590.90909091
33409090.90909091
53955681.81818182
 is. but the public nodes verifies that simple maths of add and subtraction, that mathematically the numbers cancel eachother out to atleast know the values.. whatever they are, pay in and out correctly

this is the simple bases of confidential payments.

---

next mimble,

mimble adds to the confidential payment, with the premiss that one manager(fred) has the masterkey of MANY unspent multisigs. so it can grab unspents from many blocks and form a new transaction anytime he pleases, using any/all unspent multisigs he manages

so that analysts can no longer confirm or deny if alice and bob wanted to buy something, how much, when, why... because the funds are moved into a large reserve by one person(fred). and fred is then incharge(cross your fingers he is ethical/honourable) of repaying whomever, whatever amount is owed to them

imagine fred picks another multisig to mix with dave and alices multisig
 a multisig address is created between dave, kim and fred.. dave and kim are the 2-of-2 and fred is the manager with a masterkey
the multisig is 3bobalicefred
(for time/laziness sake lets just say dave and kim pay in same amounts as alice and bob did)
and now fred is moving the funds belonging to dave and kim

[in: 3davekimfred value=20546590.90909091]
[in: 3davekimfred value=33409090.90909091]
[out: 3fredmultisig value=53955681.81818182]
signed fred
commitment: bcd2b8e028b1d215bb3cb3a9a693d023c4cb906820ba423be1282590eb41bdc9

[in: 3fredmultisig value=53955681.81818182]
[in: 3fredmultisig value=53955681.81818182]
[out: 1robert value=39088636.3636364]
[out: 1alison value=16704545.4545455]
[out: 1david value=17205681.8181818]
[out: 1kimberly value=33409090.9090909]
[out: 1frederic value=1503409.09090909]
signed fred
commitment: bcd2b8e028b1d215bb3cb3a9a693d023c4cb906820ba423be1282590eb41bdc9

issues.
1) because fred is using the same commitment (math) for everyone to ensure public validation without revealing true value
then analysts will eventually decode the numbers, simply by analysts doing a few transactions with fred and then the commitment math is revealed
2) to do this. each transaction has to include kilobytes of excess data for the commitment
3) it involves allowing a masterkey holder to move funds to mix together multiple peoples funds to try confusing analysts.

which is too much bloat for such a temporary idea of hiding value from the public, and also violates the bitcoin ethos of permissionless peer to peer trustless ideology of bitcoin.

no they werent

many of us early adopters were following your endless rants and your drug induced paranoia and in the end we came to the conclusion you get drunk/stoned some nights, think up some epic story of no relevance and then want to entertain the world with your rants.

please either go to some drug support group, or set a long password for your computer login so that you have to think rationally before typing anything.

most of your posts belong on the sci-fi section or the crime drama of some story telling website.

many people have come to the conclusion you are high when you post your nonsense, so take it as a hint

unicode:
U+048C    Ҍ

?

lauda.. do you even understand malleability.
and how it is not a problem in multisig, and how RFB CPFP are the replacements for double spends. meaning malleability is not a big deal, because solving malleability solves nothing.

its been an 'issue' but not a big deal problem... after all ~2000-2500tx every ten minutes for the last 2 years have had no massive complaints/problems. the only time it was of any drama was a couple years ago when kerpeles used it as a fake reason to embezzle funds and blame bitcoin.

even the latest exchange embezzlings, which fake cried hacks didnt use the malleability screams of lost funds, because they know people would laugh at them because of the obvious fake excuses if they did blame malleability

wake up and research. learn that people have found work arounds and ways to double check and reduce risk

its time you spend less time being spoin fed on IRC and instead do your own independant research

HELLO
wake up

advertising bitcoin is not the problem.

using bitcoin is.
it needs to be simplified!!
even hardware wallets need to be revamped. the issue is that it is too cumbersome, complicated and needs downloads/browser extensions or server access.. plus needing to copy and paste lengthy gobbledegook addresses and decimal numbers

but there is a solution, should someone want to do it.
SMART WATCHES/FITBIT wristbands

just google "programmable smart watches with NFC" and you'll see the tech is available.


barclays are ahead of the game. first they are doing it with their native fiat payment method,
https://www.shop.bpay.co.uk/categories/buy-bpay/product/wristband/wristband


but barclays is knee's deep in hyperldger so next will be a hyperledger wristband, which will make hyperledger (bitcoins altcoin(banker) competitor) appealing to people that are not paranoid geeks

this is why litecoin, vertcoin and other alts are also doing LN. so that a future LN client can interact with many coins and swap independently and settle on all blockchains at a later('withdraw') time.

but all LN concepts at the moment still have flaws, so its too early to tell

the individual public keys used to form the multisig are empty of value. thus no need to 'coldstore' exactly.
because they are separate, that alone is a line of defense

because multisig involves dual signatures. an exchange via API can sign the tx(not on the front end) send the signed tx to the front end and then the front end sends the signed tx via api to the customers LN/multisig client.
thus the private key is not on the front end and transmission time is miliseconds (think how proxies work)

knowing the customer needs to sign too. the customer would refuse to sign if it noticed the destination of funds were going elsewhere. thus a hacker cant intercept. and also a hacker cannot change the destination after signing because the signature wont match the tx's new content.

lastly the customer just sends back a copy with their signature, thus also protecting their own private key by not having to use the privatekey within the exchange front end. but only on their own personal computer

because tx's are using real unspent funds and double signed it cant be double spend because funds cant move without both sides agreement.
and thus its no need to broadcast it to the network instantly. just holding a tx becomes like a bearer bond/promise/guarantee to pay.


current LN concepts do have MANY 'penalties' so although you can re-sign thousands of tx's at an agreed lower fee per re-sign. LN hubs want to introduce other ways to make money, hold funds and revoke funds. so LN has some faults.

hense why im more interested in traditional multisig utility which has been built into bitcoin for along time now. but lets hope the LN concepts aimed at repaying blockstream investors is not so heavy handed with its penalties, otherwise LN will be impractical

the shapeshift model wont work for daytraders.

but multisig/LN would.
this is because instead of seeing some mysql 'balance' you are seeing a signed tx of real unspent bitcoin value between you and an exchange and shows who owns what share of that value.
EG
[in: 1cU5t0m3r: 1.0btc]
[in: 13xCh4nG3: 1.0btc]
[out: 1cU5t0m3r: 0.999btc]
[out: 13xCh4nG3: 1.001btc]
[sig: 1cU5t0m3r]
[sig: 13xCh4nG3]

and that tx changes and gets resigned when a customer places an order (example below of placing an order for another 0.001btc)
[in: 1cU5t0m3r: 1.0btc]
[in: 13xCh4nG3: 1.0btc]
[out: 1cU5t0m3r: 0.998btc]
[out: 13xCh4nG3: 1.002btc]
[sig: 1cU5t0m3r]
[sig: 13xCh4nG3]

when the customer want to 'withdraw' he just broadcasts that tx to the network to get confirmed
the exchange cant run away with 2btc because he needs the customers signature
the customer cant run away with 2btc because he needs the exchanges signature

so they both have to mutually agree on who owes who what and both sign to show agreement

2.1mb IF 100% of people made 100% segwit versioned transactions compared to legacy transactions.
so 2.1mb is the best possibility. not the realistic expectation

its also funny that lauda has quietened down on the linear/quadratics debate now that i think he knows that an LN settlement is just a 2in 2out transaction. thus the amount of sigops is small and not an issue especially when an update to the libsecp256k1 brought a 5x efficiency gain.

lastly. LN relies on dual signing. so parties can check and double check the contents of a tx before signing to see if its able to malleate. thus by signing, the other party cannot then make another tx because it requires dual signatures. thus malleability is not an issue. they would refuse to sign a tx if it were showing the signs that the first tx was malleated.

im also laughing how core and their fanboys want to offset LN into the litenode category and then offer third parties to 'outsource' (paid to manage) the mainnet server connection to LN. where the manager has control to deploy revoke codes. and take a fee, impose a penalty
um hello. delayed spendability(AKA 3-5 banking day fund maturity/spendability (CLTV)) revoke codes (chargebacks (CSV)) and middleman management paid service(outsourced monitoring)...

LN has its utility but lets not kid ourselves. its just a 'banking' service that should be voluntary on the side.. not to be pushed as the end/only solution for bitcoin.

LN is not a permission-less, open, trustless system.
dual signatures = permissioned
outsourced monitoring = trust required

atleast be honest with yourself and sell LN on its real merits for the certain niches where it would be useful(exchanges, faucets, adsense, gambling). rather then overselling LN as the ultimate solution for everyone, while hiding its limitations and issues that will make it impractical for some people that actually dont want middlemen and locked funds managed with excess fee's/penalties, chargebacks and settlement delays.

LN is being pushed not for the benefit of bitcoin. but for the benefit of blockstream becoming the outsourced managers so that they can claim fee's and penalties to repay their investors.

no point upgrading.

after it activates then core will spoon feed out an actual fully functioning segwit release with full wallet functionality for segwit.

this 0.13.1 is just an empty gesture to make people feel like they are part of segwits desirability promotion. yet they are not part of the vote or veto power of true consensus.

its got little to do with energy costs

put it this way an asic in asia pays $225 electric per ASIC for 6 months.
in america its about $450

meaning only a couple hundred dollars difference spread over 6 months.

the real cost however is the ASIC itself.
because america doesnt make an asic they have to shell out $1500 per rig.
however it costs asia to make a rig just a couple hundred. so when they sell the rigs to americans. the asians can make many rigs. one to give america a couple to keep themselves and still some fiat spare to pay the electric for them couple rigs that cost them nothing thanks to the american consumer.

thus its pre profit for asia to mine. all because they make the rigs.. not due to electric costs