Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - taera249

Pages: 1 [2] 3 4
16
Node discovery relays and some people argue that it cannot be done and it must be well complicated to calculate the
hops by the time you have to deal with fees and the reliability of intermittent nodes plus ensuring the nodes each have
sufficient balance in the ledgers to carry out the transaction.

I can only imagine the amount of code needed to make this happen so once again as was the case with mining coins
that lead on to CPU-Wars it seems to me like the solution is worse then the initial problem and from a performance
perspective this would be slow if hub/banks were all Alice, Bob, Peter and Paul

Every node for himself just to keep some academic dip sticks happy without more specialized nodes looks like a big mess
to me but if they want to proceed down this lightning route then maybe the need a cluster of routing servers (DNS Type thing)
with plenty of redundancy built in to the system.

Time here is critical because a route could be found but milliseconds later the balance sheets has changed and the funds are
no longer available to carry out the transaction and lets also remember we now have some centralization and transaction won't be in
this wonderful magic things called the public block-chain.

No wonder it taking them years to program this thing and its so hard to understand

17
News / Wallet and platform for 100 low value currencies ?!
« on: January 25, 2018, 01:05:12 pm »
Android wallet Coinomi supports many coins. But, it's closed source, and keeping all your coins in a hot wallet for long term is bad practice.

For secure storage, you shouldn't rely on just one wallet that covers all, you should research all coins individually, and choose the best wallet for each coin. I prefer to keep each wallet in it's own VM.
Research, installation, backup and funding is quite a lot of work per coin. But, it also prevents you from just buying 100 random coins without having any idea what you're getting into.
You could make it a goal to buy 2 coins per week. That also means you'll have to research more than that, as you shouldn't just buy any random coin. This way, you'll buy 100 coins over the course of this year. If you're seriously going to do this, I would be very interested if you keep track of all your coins in a (self moderated) topic on this forum.

18
News / Still possible to bootstrap blockchain via Torrent?
« on: January 25, 2018, 01:04:16 pm »
Chances are, if you were to download the bootstrap using an external source, the process would take longer than if you synchronized it using the client. The client can synchronize and download the Blockchain from your peers simultaneously. This would be way faster as opposed to if you were to get the outdated bootstrap and have the client verify it at the end.

If you want any significant speedup, you would have to find someone with a pre-validated data directory so that your client won't have to validate it all over again. I wouldn't consider this as secure as the other methods though.

19
News / Movie about Bitcoin's underlying technique
« on: January 25, 2018, 01:01:41 pm »
Hi Folks,
 
I made a movie about Bitcoin's underlying technique.
Since English is not my native language, I would be glad if you watch the movie and give me some advice if necessary.
Currently the film is accompanied by an automatic voice. I'll change that later as soon as I know that the text is somehow understandable.

So, its still a draft:
https://youtu.be/I6RoG2L7Qsw

Thanks for any feedback.

20
News / Question: Hashgraph
« on: January 25, 2018, 12:58:27 pm »
Is this the correct thread for this topic ? I will give my 5 cents anyway

My understanding of hashgraph is that it will use timestamped "blocks", not really blocks but lets use that for this explanation.
When a node gets a transaction it will tell a few other nodes about the transaction, those nodes in turn would do this too and so on it will propogate throughout the network. Each node tells the other one about it with a timestamp attached. This timestamp is a basis for a transaction to be valid. When a certain amount of time is passed then  that gets set as the "block". This is my understanding of how it works in a basic form.

This uses a legacy protocol called gossip protocol, this was developed in the 1960's or something. It was never really used much. Which brings up concern number one for me, if this legacy protocol is the base of hashgraph then how do we know it has been stress tested and battlehardened. Even today we find exploits with TCP/IP. TCP/IP is the basis for the internet and networks as we know them today.
Let's face it, programmers today know a lot more than the original creators did in those days, applications and protocols are developed with security in mind.

Then onto the way transactions are advertised. This sounds very similar to some more legacy networking technologies (Such as RIP routing protocol), I am unsure of what kind of loop prevention they have. From what I have read about it I don't  see a fool proof loop prevention mechanism in it, I can think that if I recieve a gossip packet  from someone else I can just modify the timestamp in the header before passing it on in my node (this might screw with the whole system). As the network grows the bandwidth requirements will probably start getting quite large which means it wont  be usable on mobiles.
I didn't research this extensively though, so this point might be mute. But the bandwidth requirement will go up as the network scales. Which I think is a bit of a problem, there should be a set limit as to how many confirmations are needed for a transaction to limit the bandwidth requirements.

My biggest problem with this, like others have stated is the fact that this is patented and  developed by one company. I'm sure it will have some uses, but I dont see this replacing blockchain. Blockchain is starting to become really cool, modern blockchain 3.0 products really lay the ground for mass disruption and previously unthinkable innovation. I don't see hashgraph bringing such extensive scalable smart contract technology to the table.
If it's not open source then that means we can't see the code, that means we need to trust the entity who created it. With BTC and others the code is there for anyone to read and check, meaning we don't need to trust anyone, which is the beauty of blockchain.
"Each node in Hashgraph can disseminate sealed information (called events) about transactions created and transactions received from others, to other nodes chosen at random, these nodes will add the received events with the information received from other nodes in a new event, and then They will send to other nodes chosen at random, this process continues until all the nodes know the information created or received at the beginning, and the new information can reach each node of the network in a very fast way.

Fast: 250,000 transactions per second. (7 transactions / second in BItcoin)
More just: Better mathematical configuration (with 2/3 of the network the transaction is validated). For example, a miner could NOT decide which transaction to "make" before due to the higher fee payment.
More secure: It is asynchronous. Nobody can avoid reaching a consensus or trying to interrupt one that has already been reached.
Efficient: No new block can become obsolete.
Less storage: Allows if an event occurs, everyone knows it in minutes, and only the transaction is saved, everything else goes straight to the trash.
Less electricity costs: As they do not rely on PoW (work proof), there are no miners nor would that amount of electricity be consumed. "

This is a bit of the information I found about it.

21
News / Lightning network - fast and low fees
« on: January 25, 2018, 12:55:55 pm »
Lightning network is well complicated and has lots of code to deal with transactions within
the network so if a banking hub (in theory) goes bad you can broadcast to the BTC network
to get you money back

See white paper https://lightning.network/lightning-network-paper.pdf

what people are not getting about lightning is that just because you deposit your
money at the bank in a ledger it is not the banks money (You can get it back) and the bank has to forward
it own money out from a separate ledger on to the next bank before Alice gets paid

See http://forum.cryptolivecap.com/posts/t31-Lightning-Network 
Dave is this case is the bank  or watch https://www.youtube.com/watch?v=UYHFrf5ci_g

22
News / Automated Bitcoin Payments
« on: January 25, 2018, 12:45:42 pm »
Hi all,

I want to run a script once a week that sends an amount to a specific address. The amount sent is decided by how much was deposited into the account during the week. For instance the wallet must always have 1 BTC in it and anything over that is sent to the new address each week.

The OS i am using in ubuntu on a Raspberry Pi 3 and i know how to schedule the job using crontab but i do not know how to write the bash script. The bitcoin daemon and bitcoin-cli are all hosted on the same machine as the script.

so far this is what i have.

#!/bin/bash
if [ $(echo "$(bitcoin-cli getbalance) > 1" | bc) -eq 1 ];
then
      bitcoin-cli sendtoaddress ADDRESS $(bitcoin-cli getbalance - 1) "Automated Payment"
fi

Does anyone have any suggestions on how to improve this?

Thanks

23
News / Bitcoin RPC. Get sum of all fees in the mempool.
« on: January 25, 2018, 12:43:11 pm »
I'm trying to get a number of total fees in the bitcoin mempool (live, in BTC) using python.

I was able to connect bitcoinrpc, but stil struggle with commands and a proper way of acquiring the number. One way of doing this would be to get information on all unconfirmed transactions in the bitcoin mempool and sum their fees, however running the code below returns me an empty list.


from bitcoinrpc.authproxy import AuthServiceProxy, JSONRPCException

rpc_user = 'xxx'
rpc_password = 'xxx'
rpc_connection = AuthServiceProxy("http://%s:%s@127.0.0.1:8332"%(rpc_user, rpc_password))

transactions = rpc_connection.listtransactions("*")

24
News / DagCoin: a cryptocurrency without blocks
« on: January 25, 2018, 12:39:59 pm »
DagCoin: a cryptocurrency without blocks

Back in 2012 I thought a lot on a new cryptocurrency that could merge the concepts of transaction and block. Each transaction would carry a proof-of-work and reference one or more previous transactions. The resulting authenticated data structure would be a Direct Acyclic Graph (DAG) of transactions where each transaction “confirms” one or more previous transactions. The confirmation security of a transaction would be measured in accumulated amount of proof-of-work referencing (or confirming) the transaction. This structure is well suited for a cryptocurrency without subsidy (such as a side-chain). On the past years I’ve read a couple of similar proposals on bitcointalk (although I cannot find the references now). When the GHOST paper was published, I perceived it as a reinforcement of my idea that a tree could give more security than a chain in case of high rate of transactions.

My open problems…

The problem that I could not solve in 2012 is how to limit the maximum cut of the generated DAG or, in other words, how to prevent all new transactions from referencing the same set of parent transactions. How to create the incentive to “move forward”? The DAG must not increase in “width”, and it should look more like a DAG-chain. Also one must prevent users from choosing old transactions to extend the DAG. I tried several monetary incentive structures to force users to choose newer transactions, but with no result. To know the last “ledger state” there must be a way to consolidate branches. Merging branches should be good, but not too good such that everyone starts merging the same branches over and over. The problem of spam was also less important, as no transaction would be able to get a “free ride” in a block, as each transaction carries PoW. Ultimately the owners of a computer that is being part of a spamming botnet would realize their computers have been hijacked based on the amount of CPU consumed. For instance, if a transaction requires a proof-of-work that takes 1 second in a standard PC, and each transaction is 400 bytes in size, then a botnet consisting in 10K computers may create transaction reaching 3 Mbytes/second. This high network bandwidth usage itself is not a problem, since it can disrupt the network only as long as the attack is active. However, there must be a way to prevent the DAG-chain from growing at that pace. It turns out that the election of an optimal data structure allows the DAG-chain to be compressed, but it requires us to change how we think about double-spends, and how we conceive the “ledger state”.

A Radical Change

The leap of faith required to find an out-of-the-box solution is to think about double-spends not as a boolean attribute, but as a probabilistic attribute, based on comparing the confirmation work on competing transactions. An the security of a transaction, as the confirmation work compared to the the work expected that an adversary may use. Also it requires to forget about the concept of a “global ledger state”. In Bitcoin there is a global ledger state. Chain reorganizations can always rollback the state, but the state is globally consistent. There is a certain probability of the last block rolling back, but the probability is the same for every transaction in that block. In this proposal, the ledger state is just the overlap of all possible transactions, each with its own confirmation probability, and there is no consistent global state.

Design Premise: “The cryptocurrency network benefits from creating a DAG growing as “thin” as possible.”

In other words, having the average maximal cut as low as possible. It seems that referencing many previous transactions (high out degree) can make the DAG thinner only if the following transactions reference the transaction with high out degree, but are themselves of low out degree. So we want high out degree some times, but low out degree another times.

I designed a DAG that tries to fulfill that premise, and an associated incentive structure such that:

 There is a benefit for users to reference as many previous transactions as possible
 Referencing many previous transactions is incentivized only when there are many previous transactions unreferenced.
 There is no competition between users to reference a previous transaction.

Here is the paper draft  –> DagCoin-v4 https://bitslog.files.wordpress.com/2015/09/dagcoin-v41.pdf

This same article can be found in my blog: https://bitslog.wordpress.com/2015/09/11/dagcoin/

25
Announcements / Having fun with crypto.
« on: January 24, 2018, 07:41:19 pm »
Hey folks,

Long time listener, first time caller.

Just started compiling litecoin, but I've been into crypto since 2013 and I'm an engineer so this is pretty fun.

My master plan is to release my own coin.

Going for a true sh1tcoin with a $500 market cap! to the moon!!!!!!!

   
MurfCoin Engineer No. 001 - May the FLUFF be with you.
http://www.murfcoin.org
http://explorer.murfcoin.org

26
Announcements / How to start bitcoin development
« on: January 24, 2018, 07:24:18 pm »
Bitcoin is free software and any developer can contribute to the project.
The first: Code Review

Bitcoin Core is security software that helps protect assets worth billions of dollars, so every code change needs to be reviewed by experienced developers

The second: Starter Projects
Fix existing issues:  Before starting to write any patches for issues you find, you may want to comment on the issue to make sure nobody else is already working on it.
Write tests
Documentation: you should start by exploring the developer documentation.
And finally, Developer communities : you can read their rules of conduct which host discussions about Bitcoin development as
IRC Channel #bitcoin-core-dev on freenode.
Bitcoin Core Slack Channel
Bitcoin StackExchange
BitcoinTalk Development & Technical Discussion Forum
 Good luck for you

27
Announcements / Question regarding addresses starting with 1-bc1-3
« on: January 24, 2018, 07:23:18 pm »
Anyone can tell me if....

- An address starting with 1 is not segwit
- A bech32 address (bc1) is segwit

Are we ok? but...

- An address starting with 3 may be segwit

Don't we have yet a method to see if the address starting with 3 is a segwit or not? Or only once spend we are able to see if the P2SH is segwit or multisig

Thanks  Undecided

28
Announcements / Why didn't bitcoin scale using both proposed solutions?
« on: January 24, 2018, 07:22:21 pm »
Hi Forum
Hoping you can educate me a bit here. I wasn't heavily into crypto at the time this all took place.
When the whole scaling debates began basically two solutions were proposed, which as we know lead to the creation of BCH.
Why did we not move BTC to 2MB blocks while work on the layer 2 scaling was being finalized? As I understand LN right now when a channel is closed the transactions in it get processed by the main chain, thus a bit of extra blocksize would help scale LN even more.

To me, I personally like the idea of layer 2 scaling more because of all the features it would add to BTC and new things it would make possible. I see some merit in both solutions though.

Is there a good reason apart from politics that we couldn't have just done both? It would have carried us for now until new scaling solutions are done and fully tested.

The BTC vs BCH has really split the community, yea there's some funny memes around this and all, but its not good that we are all fighting each other and getting super opinionated around this. I hope we don't see more separation in the community in the future.

P.S. lets not turn this into a BTC vs BCH argument here, make love not war Smiley

29
Announcements / How to use Segwitaddress.ORG ?
« on: January 24, 2018, 07:20:44 pm »
Friends,
I've seen that being non-user of SegWit, there are no such benefits or advantages that we can accrue.
So, I wish to learn how to switch to SegWit completely?

I became aware of Segwitaddress.org to create an address directly from there, but if I use that address, will I be able to sign messages through that address (as the address is being provided with the private key itself)?

I also used an option that asks for a "WIF Private Key" (I entered my Legacy address, i.e.; 19RidcN96xgXkWi8gDwxcmbjjdjfrxpxvv's privkey) there and got an address that could be used to receive funds. But what I don't get here is, where will I see those funds and where can I use them from?
I mean, if I use the same privkey in any wallet, it will still show 19RidcN96xgXkWi8gDwxcmbjjdjfrxpxvv as my address and not the one I get from segwitaddress.org, what should be done here? As well, should I keep me Legacy address' privkey even if I adopt SegWit completely?

30
Announcements / Increasing Supply Limit.
« on: January 24, 2018, 07:19:52 pm »
Good Day Everyone!
I think this is the most appropriate section where I can post my question regarding the development of Bitcoin.
I just read the Bitcoin whitepaper and most of it content are difficult for me to understand, lots of them are Mathematical Equation and programs. Upon reading  there is only one question. that pops in my mind.
What processes or steps in order for the creator to increase its Supply Limit? [I am also pertaining  to Alternative Coins not just Bitcoins]. Someone says that it is complicated.
Can you cite some relevant previous post or links?
For you to change the total supply of the Coins that can be mined it can be done with a hard fork but, another coin would just be made with the name Bitcoin on it. it's imposible for you to change the supply it's made only to have 21m on it (BTC).

Pages: 1 [2] 3 4