Latest posts of: franky1

Quote from: IadixDev on February 20, 2017, 12:10:22 PM

I was thinking about something in this same line, having the memory pool used as some kind of optimization layer above the block chain, to pre process certain transaction and spare them from the mining pool.

you do know there is no central mempool.

every node has their own mempool. and as long as a node is not deleting transactions for random non-rule reasons each node keeps pretty much the same transactions as other nodes... including the nodes of pools. the only real varient is if a node has only just been setup to not have been relayed the transactions other nodes have seen.

pools and nodes validate transactions as they are relayed to them. thus when a block is made there is less reason to re validate every transaction over again.(unless they are new to the network to have not seen the relayed transactions. or as has been hypothesised in this thread. where nodes are biasedly rejecting transactions for no rule breaking reason)

sigops
the way bitcoin is moving, most nodes would have pre-validated the transactions at relay. and all they need is the block header data to know which transactions belong to which block. so sigops are less of an issue at block propagation because the validation by most nodes is pre-done.

if we start not relaying transactions then all of a sudden nodes will start needing to request more TX data after block propagation because some tx's are not in a nodes mempool. we should not be rejecting tx's because it will slam nodes later, causing block propagation delays

however we should think about changing something real simple.
the tx priority formulae to actually solve things like bloat/respend spam. where by the more bloated (tx bytes) and the more frequent (tx age) a spend is made. the more it costs.

the old priority fee solved nothing. but was used to just make the richer tx's gain more priority but a small value tx left waiting weeks to get priority.

so lets envision a new priority formulae that actually has real benefit.

imagine that we decided its acceptable that people should have a way to get priority if they have a lean tx and signal that they only want to spend funds once a day. where if they want to spend more often costs rise, if they want bloated tx, costs rise.. which then allows those that just pay their rent once a month or buys groceries every couple days to be ok using onchain bitcoin.. and where the costs of trying to spam the network (every block) becomes expensive where by they would be better off using LN. (for things like faucet raiding every 5-10 minutes)

so lets think about a priority fee thats not about rich vs poor but about respend spam and bloat.

lets imagine we actually use the tx age combined with CLTV to signal the network that a user is willing to add some maturity time if their tx age is under a day, to signal they want it confirmed but allowing themselves to be locked out of spending for an average of 24 hours.

and where the bloat of the tx vs the blocksize has some impact too... rather than the old formulae with was more about the value of the tx

here is one example

as you can see its not about tx value. its about bloat and age.
this way
those not wanting to spend more than once a day and dont bloat the blocks get preferential treatment onchain.
if you are willing to wait a day but your taking up 1% of the blockspace. you pay more
if you want to be a spammer spending every block. you pay the price
and if you want to be a total ass-hat and be both bloated and respending often you pay the ultimate price

yes its not perfect. but atleast lets think about using CODE to choose whats acceptable. rather than playing bankers economic value games of rich guys always win, that way we are no longer pushing the third world countries out of using bitcoins mainnet.

the only way to prove the "buyer" was the buyer. is if you have a picture of the buyer holding a piece of paper saying something related to the sale.

otherwise the account owner can just say he was not physically the "buyer". and someone stole his paypal credentials.
though advice above is not 'official' it atleast can be used as some form of proof of the human you were trading with

you can however try to get paypal to look at the geo location metadata of the paypal transaction and compare it to other paypal transactions the "buyer" done prior to the scam and after the scam.

if the geolocation data matches then obviously it was the real owner of the paypal account.
but you still should have done some due diligence and made sure who you were trading with was not just a username someone hacked.

Quote from: European Central Bank on February 19, 2017, 11:54:30 PM

Quote from: DoublerHunter on February 19, 2017, 10:53:58 PM

High fees is not a valid reason to leave bitcoin because it is one of needs of bitcoin especially the miners because if they didn't get enough fees then they can't create profits for a living and they will start to shut down their mining rigs. I believe that high fees are just temporary since the bitcoin is just on its young age but after a few developments, bitcoin will be strong enough and high fees will minimize.

fees have to keep on rising. the question is whether they're allowed to be paid by increased capacity so they stay reasonable for everyone. if they don't then it'll be bye bye from more people.

the fee war is NOT a problem for miners today. but is a problem for users
its still a concept that will become a problem for miners in DECADES. not today
we should not be pushing the fee's up so high right now. pools dont need it.

infact pools dont actually care about fee's. to them its a BONUS not a required income.

we need to concentrate on ONCHAIN scaling so that NATURALLY over decades the tx count grows NATURALLY (not overnight, so dont throw the gigabytes by midnight rhetoric)

this also doesnt mean let corporate devs put a halt on natural onchain scaling and use false rhetoric of 'conservative' buzzwords as their word of the year to hold off on natural scaling to push their corporate commercial services.

if your worry is a nuclear bomb causing an EMP in your location.. chances are the radiation is going to burn your skin and kill you before you get to buy a new car/house with your bitcoin.

Quote from: manselr on February 19, 2017, 04:17:59 PM

Yes, segwit isn't needed for payment channels, but segwit adds a lot of cool stuff, including schnorr which can make bitcoin more private. The positives of segwit outweight the cons, everyone knows this its 2017.

seems your reading a script.

schnorr doesnt even add any benefit to LN either.
LN uses multisig.
so it still requires 2 signatures. not a single schnorr sig

so its not going to make any benefit to LN.

yes for other transactions where someone has many unspents of one address to spend.. can reduce the list of signatures because one sig is proof of ownership of all the unspents to the same public address. instead of signing each unspent. but its not needed for LN

plus people wanting to spam the network. are not going to use schnorr with their dust inputs. they will stick with native keys to spam their tx's. so even schnorr is not a 100% spam fix. again empty gesture

Quote from: manselr on February 19, 2017, 03:23:50 PM

activating segwit then max up with LN for VISA competition purposes.

segwit solves nothing because people wanting to spam and double spend scam will just stick to native keys. meaning segwit is just a gesture/empty promise. not a 100% fix.

LN can be designed without segwit.
after all its just a 2in 2out tx which is not a problem of sigops. and not an issue of malleability.
LN functions using dual signing. so its impossible for 1 person to malleate because the second person needs to sign it and could easily check if malleated before signing and refuse to sign if someone malleates.
and the person malleating cannot double spend by making a second tx because again its a dual signature. so again LN doesnt need segwit

nothing is stopping a well coded LN to be made.. we just dont want devs to think a commercial hub LN service to be the end goal of bitcoin scaling. it should just be a voluntary side service. much like using coinbase or bitgo

the OP's link seems to be looking at the "buy" order data of exchanges, by grabbing data from the different fiat trading pairs of different exchanges.. though interesting view of exchanges. ofcourse its only a small scope of the entire bitcoin economy.

still it can show some peaks and dips of certain exchange 'buy' orders as time goes on

part of blockstreams plan with the whole 1mb base 4mb weight
is that with the 'spare' 1.9mb excess weight allowed after the maximum projected expectation of tx growth if 100% of people utilise segwit keys(2.1), this 'spare' 1.9mb can allow room to bloat a tx by adding confidential payment codes onto the tailend of a tx (outside the base block)

making a standard 450byte tx in REAL data terms be upto1.5kb to become 'confidential'. but twisted to not count all them extra bytes within the base block.

many are laughing that with segwits failures to actually fix malleability and sigops, due to malicious users simply not even going to use segwit keys after an activation and sticking to native keys.(thus making the segwits promise broken/ half baked)

we must come to the realisation that the 1mb base block concept of segwit. is not about keeping 'data'/bandwidth down. because real data still exists beyond the base block.(upto 4mb)

so knowing blockstream will allow bloated transactions, and happy with upto 4mb 'bloat' but not caring about real transaction count increases, their best expectation is where we could end up with 4500tx max for 4mb(with confidential payment codes included)

however
....instead we could do a proper onchain scaling to allow more REAL transactions(native too).. not just a few segwit transactions to scale

we could go back to basics of simply having 4mb real block space(or even dynamic blocks which adjust by what nod consensus agrees to). where it still allows segwit transactions and confidential payments.
but where all of this is done by an actual node followed by pool vote. rather than blockstreams half baked method.
allowing transactions upto 10,000 native transactions(without CPC). all without going beyond blockstreams new 4mb happy bloat number.

as for the empty doom of fear of altcoin creation.. blockstream have already openly threatened they would happily bilaterally fork the network to get their segwit activated. so going soft is not even preventing that doom(i laughed and facepalmed when that strategy was revealed)

thus just a 4mb blocksize allows native transactions to have more transaction count ability. thus a real onchain scaling. and all the other stuff all within the same metric.

but this ofcourse means blockstream have to back down on their power grab of moving people away from native bitcoin transaction. and trying to be the upstream filter gate keepers.. and instead start playing with the other bitcoin teams and be on an equal playing field and allow real onchain growth.

thus they still get their transaction features and the rest of the community get the native transaction scaling..
thus both get to have the cake and eat it.

the network is the network.
the code is the code

but if you wanted to change your own node to display a different name.. you can
some call it "btc" some call it digital gold. some call it revolutionary money.

you are free to call it whatever you like.
however this name you choose does not impact the code or network.

more popular, people are changing how the units of measure of the currency are displayed.
some use mbtc, some use 'bits' some use 'satoshi'

again this is just personal choice that does not affect the network or code.

call it whatever you like. but try and get everyone to agree to it.. thats a whole different story

same with dollars
some call it dollars.. some call it "greenbacks" some call it by many names. but its all the same thing.
no one can agree on all the pet names individuals give it but they atleast accept dollars have more then one name and they know whatever its individually called.. it doesnt change what the actual currency is.

so if you want to talk to people about satoshi's or bits. you can.
if you want to talk about the currency as BTC and the protocol as Bitcoin. you can.

Quote from: kiklo on February 18, 2017, 08:43:39 AM

Charlie Lee claims he can force segwit on them no matter how the miner vote.
http://www.newsbtc.com/2017/02/17/charlie-lee-potentially-enforcing-litecoin-segwit-activation-bitcoiners-concerned/

coblee and gmaxwell do have a trick up their sleeve.
its called a bilateral split. commonly known as an intentional altcoin creation.

yep both know that they can cause a bilateral split even in a soft scenario

Quote from: coblee

Of course I would rather we all work together for the best for Litecoin. But the checks and balances that exists within Bitcoin/Litecoin gives users the ability to overrule miners if needed. Most people are not aware of this and think that miners are in control.

Quote from: gmaxwell on December 28, 2016, 05:40:35 AM

If there is some reason when the users of Bitcoin would rather have it activate at 90% .. then even with the 95% rule the network could choose to activate it at 90% just by orphaning the blocks of the non-supporters until 95%+ of the remaining blocks signaled activation.

yep.. they are willing to cause an intentional altcoin to get segwit activated..even in a soft scenario

yet. if willing to go to the extremes of causing an alt to get what they want. they should have saved 2 years of bickering and just went with a PROPER full node and pool consensus which would not result naturally in an altcoin.
(but with the same stupid chance some numpty might want to push the issue into causing an altcoin, which they now admit is the same for soft)

that way by doing a full node AND pool consensus they could have also included the features the community really wanted in the first place. thus giving the entire network a real confidence of positive movement of onchain scaling.

Quote from: Foxpup on February 17, 2017, 02:50:30 PM

Nobody said anything about your grammar, and your embarrassing mistakes were more than a typo. After all, nobody deletes their post just because they made a typo.

if all you can do is knit pick someones wording but not the code concept. then read the code concept

i was typing to fast.. oh well. grammar nazi

consensus.h BLOCKSTREAM_CORE_MAX_BLOCK_SIZE = 1000000-16000000; (1000000 currently in some nodes) - what nodes can cope with
policy.h DEFAULT_BLOCK_MAX_SIZE = 750000-999000; (999000 currently) - what pools will make

same thing for BOTH core and BU just a word change.

consensus.h MAX_BLOCK_BASE_SIZE = 1000000; (1000000 currently(forever if gmaxwell had his way)) - what nodes can cope with
policy.h DEFAULT_BLOCK_MAX_SIZE = 750000-999000; (999000 currently) - what pools will make

if the only knit pick you can find is someones typo.. then you need to try harder
(cores is in purple)
the point is that pools will look at what consensus (EB) settings of nodes allow and then POOLS make blocks under that(policy).

end result is ORPHANS. not persistent surviving multiple chains. just orphan drama until blockheight/chainwork reveals one single chain
if the minority is larger blocks then they happily accept smaller blocks because anything below EB is acceptable, meaning even 1mb are acceptible even if EB is 16mb or whatever
if the minority is smaller blocks then they simply cannot sync and treat everything as an orphan. thus they stall.

its the same mechanism since 2009. just reworded

the only way to create an altcoin is if the minority small block scenario BILATERALLY (intentionally) banned/separate communications from the opposition nodes. to avoid bitcoins built in orphaning mechanism

Quote from: Lauda on February 17, 2017, 09:12:41 AM

Quote from: Foxpup on February 16, 2017, 11:35:25 AM

BU supporters' understanding of consensus systems in general is completely wrong, not just decentralised ones. I don't know why; it's a simple concept: it means that several independent implementations of a program given the same input data will give the same output, and those that give different results will automatically be known to be wrong. In the specific case of Bitcoin, it means that given multiple conflicting transaction chains, of which only one of them can be valid, all Bitcoin nodes everywhere will always agree on which chain is valid.

BU's so-called "emergent consensus" is not a consensus system of any kind. It explicitly allows nodes to disagree on which of multiple conflicting chains is valid, and it's trivial for malicious miners to force a chain split among disagreeing nodes to allow double-spending. It's not even fair to call this an "attack" since this catastrophic breakdown of consensus is by design. Anyone supporting BU deserves to lose their coins, and I think they're likely to.

Unsurprisingly, this post was completely ignored because... Roll Eyes

I'm just going to state that it's well written and summarized. I'm looking forward to see how someone is going to attempt to refute it with pseudo-science.

show me the simulations you ran..
show me your stats, facts, data

oh right you just read something that did not exceed your 3 paragraph attention span (2 minute) and deemed it law because it looked "well written"

when you gain post third grade ability to read something more than 2 minutes. try learning something
https://medium.com/@g.andrew.stone/emergent-consensus-simulations-99604190fa31#.4gjxzruv0

altcoins are not created in emergent consensus. what occurs is the ORPHAN mechanism sorts out which path the majority of nodes follow.
ofcourse its going to cause orphan drama. but what you may also realise is that merchants will become weary of this around the time of an 'activation' event and take precautions to raise the 'wait for X confirm' level.

end result is if the minority is the small block size they are simply left unsynced.
end result is if the minority is the higher block size they are simply fall back to the small blocksize.
because the higher blocksize acceptors can also accept small blocksizes (remember the rule for blocksize is anything below x)

again for emphasis, no altcoin is created.

FTFY

Quote from: franky1 on February 10, 2017, 03:59:06 AM

the problem of fee's is the old 'priority mechanism
and
how the fee 'estimate' has replaced reactive fee's

but lets concentrate on a proper solution. by looking at the "priority" formulae..

(input_value_in_base_units * input_age)/size_in_bytes
target = 57,600,000

where someone with say 10btc($10,000)

100000000 *144 / 250 = 57,600,000 - gets priority

but someone with just 1btc($1000) with the exact same 'bloat' has to wait 10 days.
but someone with just 0.1btc($10) with the exact same 'bloat' has to wait 100 days.

i see a new 'priority formulae' being used onchain of bitcoins mainnet.
this is what i see as the logical punishment for bloating/respending spammers. whilst rewarding moral normal transactors, whether rich or poor

one which includes a CLTV voluntary option. where users gain priority points if they voluntarily agree to put their funds into a 1-day maturity. but those avoiding the one day before respend or have bloated transactions pay more to get into a block sooner.

EG
if you really need priority you agree that once confirmed you cant respend for a day.
it also means you can be selective of priority. by only putting a 142block wait if your happy to wait a couple blocks because it wont be priority for a couple blocks by not paying quite enough fee. allowing the age/maturity/fee variables to give a better flag of desire.

obviously those moral users that actually need to spend more than once a day could see the niche of LN as a way to transact often and cheaper.
and those that dont spend every day get priority and not need LN or to CLTV mature funds, because they are not spending everyday, anyway.

here is one example of a formulae that does not care about how much people are spending (not a rich gets priority, poor are victimised old formula), but rewards people willing to wait a day, have lean transactions. and penalises those that want to respend often or have bloated transactions

basically
if your transaction is 2x a lean tx. you pay twice as much. if 44x a lean tx you pay 44x
if you dont want to mature your funds for 144 blocks and only want to wait 1 block you pay 144x.
if the tx is both 44x bloated and wants to respend the very next block after getting confirmed then it costs 44x*144X

though my formulae is not finalised or perfect for every utility. i see how changing the priority formulae can cause more benefits for good people and penalise the bad, without making it used just to be snobby about rich vs poor. due to it no longer rewarding the rich with points just for being rich, which the old formulae done

Quote from: jackg on February 16, 2017, 07:44:41 PM

That's not really true? My bitcoin core software is set tothe default of 750kb because I don't mine with it and it syncronies with blocks greater than that amount. It doesn't reject the blocks, like you suggested. However, it would take quite a lot to get the majority vote of the mining power (around 95% it was for segwit) before the blocks were acceptd so of course the majority of miners have to accept the new block. But, if companies like Bitmain, Bitfury and the other giant mining firms considered changing that then the blocksize could increse (but it'd still take the 95% to change that).

yep meaning out of say 6000 nodes only 300 nodes will rect blocks and end up unsynced and lft in orphan hell

and 1 out of 20 pools would end up in orphan hell wher the blocks they try to create wont get height. so that pool and 300 nodes would eventually upgrade to stay with the network rather than be left unsynced in orphan hell.

remember
consensus(minority in orphan hell, not syncing)
is different to
bilateral split (intentionally banning oppositions communication's and avoiding orphans to form an altcoin)

Quote from: thejaytiesto on February 16, 2017, 05:33:14 PM

Quote from: franky1 on February 15, 2017, 11:23:59 PM

satoshi QT would be the bigbang (in your story)

core would be the invention of religion trying to change things and confuse people as to how the way of life should be.
pretending they have been around since the beginning and their rule is law, their preachers are law and everyone should follow their religion

It's funny how you use whatever you can to throw your blockstream fud propaganda. Sounds like the only cultists is you by thinking satoshi was jesus christ himself.
Sorry but satoshi fucked up numerous times as we are seeing along the way, case in point:

https://bitcoinmagazine.com/articles/how-satoshi-messed-his-math-and-how-these-academics-just-fixed-it/
Looks like god's big bang needs fixing.

im a big bang / evolution / science guy..

i dont follow people who "trust on faith" or follow people "on faith"

have a read on this as a viable opinion to how religion manipulated the truth of human evolution with their religious 'stories'.
https://bitcointalk.org/index.php?topic=1600477.msg17797892#msg17797892

i dont hold anyone up as jesus.. that is the other guys kissing gmaxwells ass..

i am a realist who was just saying that core didnt jump in until 2013. yep it was called satoshi-qt before core..
core was not around in 2009-2013.

sorry to burst your bubble

though i know you have pasted an article baiting me to defend satoshi, so you can fail at proclaiming im religious satoshi follow.. i prefer to deal with facts

so lets deal with facts
if you read the article. and read the paper.
you will see that the article is using the scenario of today (mining asics variation) but back in 2009 the assumption was 1 computer 1 miner.

so satoshis white paper of 1 cpu 1 miner results in his assumptions.
yes satoshis paper is out dated because things have moved on. but that doesnt make the past wrong. it just makes it outdated.

(yes the article is about the luck of 'time' of the blocks, im well ahead of that mathematics and scenario which then funnily enough, circles back to BLOCK-height security(confirm count) making time (their argument) moot)

Quote

Grunspan does allow, however, that simplifying assumptions in a white paper is also understandable.

Quote from: Kprawn on February 16, 2017, 04:35:25 PM

Quote from: franky1 on February 16, 2017, 02:27:12 PM

blockstream have bypassed node consensus. (for many negative/hidden reasons)

Care to elaborate on that statement, because I am not aware of any method to bypass node consensus? In my view nothing will be implemented
if consensus is not reached with a 95% majority. Huh

... If Blockstream has done this, then why are we not seeing the benefit of SegWit & LN
features? This will be interesting, if this is true. Cheesy

blockstream only want activating segwit to be done via ONLY a POOL vote.. not the USERS NODES vote.

95% of blocks
not 95% of nodes
(soft =pools only... hard= nodes then pools)

i have already said several times. if blockstream want to give the 60%+ UNDECIDED POOLS confidence.
they need to get a pool that is 'segwit ready' to make a block including a segwit TX. to show how "compatible" the network is to not need to care about the user nodes.

right now althought user NODES are not part of the official vote. smart POOLS are still hesitant to flag desire either way without seeing what NODES can cope with. so although activation is only dependant on POOLS BLOCK flags.. POOLS wont flag until thier cautious and safety concerns are addressed

simpl solution for blockstream is to bribe BTCC with $13k (out of blockstreams $90m) to make a segwit block to see if the node network cause fuss or happily accept segwit.

then that would show how "backward compatible" blocks are.
..

but i see other issues. atleast doing a mainnet test will result in either a orphan.. or acceptance.

Quote from: LLec on February 16, 2017, 04:51:07 PM

They are toting coming upto more nodes available then bitcoin core.
So what does it offer to the network in terms of benefits?
This is all that the one's sending and receiving bitcoins really care about after all.
That is their bottom line. Undecided

diversity

their needs to be atleast a dozen different "teams" of devs.
where some nodes are wrote in different codes like go, bitcoinj, etc

that way if for instance there was a bug in core. the network survives.

if only core was running the network if core has a bug all nodes have a bug.

diversity to mitigate bug risks is a security bonus.
anyone screaming that core needs to be the bitcoin king, is not thinking about bitcoin security, but about corporate centralism and security weakness

Quote from: RealBitcoin on February 16, 2017, 04:32:39 PM

Quote

Expensive servers? Don't be ridiculous. I run a full node on a computer I bought years ago for under 0.3 BTC ($300). While using that computer for other tasks as well. Sure, at some point in the future I may need to upgrade. But 0.3 BTC is not an inordinate amount to expect someone to spend to be a first-class member of the network.

Just a reminder that Bitcoin adoption is currently growing in 3rd world countries, not 1st world.
For some reason 1st worlder are perfectly happy with WU, Paypal and their banks.
And in the 3rld world, your daily wage might be only 2$. So keep that in mind.

price of tech:
bitcoin 2009 stats could easily have run on Raspberry Pi v1
bitcoin 2013 stats could easily have run on Raspberry Pi v1
bitcoin 2016 stats could easily have run on Raspberry Pi v1

raspberry Pi v3 is several times faster, bigger. so natural growth of bitcoin can run on a Raspberry Pi v3

telecom industry have a 5 yarr plan
5G mobile network
Fibre optic land line

people change their computers on average ever 2-5 years

technology is not the issue.
bitcoin wont be "gigabyte blocks by midnight", instead it will be hundred of megabyts in DECADES

we are not going to jump to "one world currency" or "excell beyond visa" overnight. it will be a NATURAL scalable amount over DECADES.

we should not halt onchain scaling out of fear of onchain scaling.
thats like shooting self in foot intentionally purely out of fear one day you might shoot self in foot.
thats like purposefully walking into a car out of fear one day you might have a car accident.

instead we need to realise what is a safe way to do things and look how to look at what to do to stay safe.

EG if nodes have a 'speedtest' built in. they can flag what they can cope with.. which then can show what the network can cope with. and the network moves with what the majority of nodes can cope with. thus no worries of outscaling nodes. because the nodes are displaying the limits.

it takes away 3dev's being king to spoon feed what they "think" the world can cope with and instead the nodes control it.