*Harambepirate shakes the forum furiously*
*Harambepirate pokes the forum with a stick*
*Harambepirate begins to cry because the dead forum reminds him of Harambe*
Topic: [ANN] SpreadCoin | Decentralize Everything (decentralized blockexplorer coming) - page 101. (Read 790391 times)
September 09, 2016, 01:21:21 PM
September 09, 2016, 12:02:02 PM
LOL ... or I did some question that I should not do, or everyone was on vacation ..
There will bubbling activity, markets, dump ... the usual
There will bubbling activity, markets, dump ... the usual
September 09, 2016, 02:58:44 AM
what is the best way to mine this coin? (There ASIC machines for this algorithm)?
In the case of graphics cards, which is the best model, and which speed reaches?
I need to think better in this currency ... LOL
In the case of graphics cards, which is the best model, and which speed reaches?
I need to think better in this currency ... LOL
September 08, 2016, 03:25:08 PM
So essentially, if I'm understanding this correctly, SNs would begin to fund Bitcoin miners and node operators?
Yes. Funding bitcoin mining via ServiceNodes is in the Whitepaper. It's not something that would happen overnight, but that's where Georgem's roadmap will eventually take us.
That link was not the latest version. I'll see if it's around somewhere.
It's in the bottom right corner of the chart.
This is one of the reasons for creating a decentralized exchange.
September 08, 2016, 12:31:58 PM
So essentially, if I'm understanding this correctly, SNs would begin to fund Bitcoin miners and node operators?
Yes. Funding bitcoin mining via ServiceNodes is in the Whitepaper. It's not something that would happen overnight, but that's where Georgem's roadmap will eventually take us.
That link was not the latest version. I'll see if it's around somewhere.
Yea, I've read the white paper. I must have missed the part about funding miners - or inconveniently forgotten about it lol.
I'll have to go back and reread that part. And I definitely didn't realize it tied into a BIP.
September 08, 2016, 12:29:22 PM
So essentially, if I'm understanding this correctly, SNs would begin to fund Bitcoin miners and node operators?
Yes. Funding bitcoin mining via ServiceNodes is in the Whitepaper. It's not something that would happen overnight, but that's where Georgem's roadmap will eventually take us.
That link was not the latest version. I'll see if it's around somewhere.
September 08, 2016, 12:21:00 PM
..
How do BIPs work anyway? For instance, if I developed one and thought it would be useful for Bitcoin. What exactly would I do with it?
How do BIPs work anyway? For instance, if I developed one and thought it would be useful for Bitcoin. What exactly would I do with it?
You need to look at BIP 0001 for that answer:
https://en.bitcoin.it/wiki/BIP_0001
However, today there is a convoluted process to test if your BIP is workable. To give it a better than average chance of being accepted, you need to develop some code or pay someone to develop some code along with your reasons for proposing a BIP. If accepted as a BIP you get assigned a BIP number. This doesn't mean a BIP gets accepted and merged into Bitcoin, but its a proposal with merit and might get merged at some future point; which basically means develop your proposal into workable code.
Lol. "BIP 0001 is the Bitcoin Improvement Proposal that proposes Bitcoin Improvement Proposals."
I'm surprised you can even propose something without code along with it haha. I guess there could be some instances in which there is someone who has a good idea but doesn't have the requisite coding skills to develop it.
Actually, Spreadcoin has one BIP that has been reserved as an advisory. Wladimir van der Laan - Lead Maintainer, stepped in when it was going to be rejected and accepted it might be something that needs to be addressed in the future. You can see a gap where ours might potentially get allocated at BIP104.
It was to do with the bitcoin blockchain potentially not being open source, even while the bitcoin software is open source.
The bitcoin software generates information and places it in a blockchain and if we are to be in a position to make money from the data to fund nodes and Bitcoin mining (to replace most user fees when Coinbase rewards drop to zero), then both the software and the data stored in the blockchain needs to be open source.
That's interesting. Why do they both need to be open source? I found the working paper - I remember that the team had been in contact with the Bitcoin devs last year at some point but I didn't remember anything much happening because of it. Or maybe I just wasn't paying attention.
This: https://drive.google.com/file/d/0BwEbhrQ4ELzBOUVtOHJQdlhvUmc/view
Right?
I quickly skimmed and it looks like Bitcoin would require a hard fork for this (being data mining rewards supplementing coinbase rewards) to happen? This is only to ensure that the data mining rewards are coded into the Bitcoin code? Would Service Nodes be separate from this? Or would they literally become a part of the Bitcoin network?
So essentially, if I'm understanding this correctly, SNs would begin to fund Bitcoin miners and node operators?
I find myself wondering why this project hasn't garnered more attention...
September 08, 2016, 11:51:24 AM
..
How do BIPs work anyway? For instance, if I developed one and thought it would be useful for Bitcoin. What exactly would I do with it?
How do BIPs work anyway? For instance, if I developed one and thought it would be useful for Bitcoin. What exactly would I do with it?
You need to look at BIP 0001 for that answer:
https://en.bitcoin.it/wiki/BIP_0001
However, today there is a convoluted process to test if your BIP is workable. To give it a better than average chance of being accepted, you need to develop some code or pay someone to develop some code along with your reasons for proposing a BIP. If accepted as a BIP you get assigned a BIP number. This doesn't mean a BIP gets accepted and merged into Bitcoin, but its a proposal with merit and might get merged at some future point; which basically means develop your proposal into workable code.
Lol. "BIP 0001 is the Bitcoin Improvement Proposal that proposes Bitcoin Improvement Proposals."
I'm surprised you can even propose something without code along with it haha. I guess there could be some instances in which there is someone who has a good idea but doesn't have the requisite coding skills to develop it.
Actually, Spreadcoin has one BIP that has been reserved as an advisory. Wladimir van der Laan - Lead Maintainer, stepped in when it was going to be rejected and accepted it might be something that needs to be addressed in the future. You can see a gap where ours might potentially get allocated at BIP104.
It was to do with the bitcoin blockchain potentially not being open source, even while the bitcoin software is open source.
The bitcoin software generates information and places it in a blockchain and if we are to be in a position to make money from the data to fund nodes and Bitcoin mining (to replace most user fees when Coinbase rewards drop to zero), then both the software and the data stored in the blockchain needs to be open source.
September 08, 2016, 11:15:11 AM
..
How do BIPs work anyway? For instance, if I developed one and thought it would be useful for Bitcoin. What exactly would I do with it?
How do BIPs work anyway? For instance, if I developed one and thought it would be useful for Bitcoin. What exactly would I do with it?
You need to look at BIP 0001 for that answer:
https://en.bitcoin.it/wiki/BIP_0001
However, today there is a convoluted process to test if your BIP is workable. To give it a better than average chance of being accepted, you need to develop some code or pay someone to develop some code along with your reasons for proposing a BIP. If accepted as a BIP you get assigned a BIP number. This doesn't mean a BIP gets accepted and merged into Bitcoin, but its a proposal with merit and might get merged at some future point; which basically means develop your proposal into workable code.
Lol. "BIP 0001 is the Bitcoin Improvement Proposal that proposes Bitcoin Improvement Proposals."
I'm surprised you can even propose something without code along with it haha. I guess there could be some instances in which there is someone who has a good idea but doesn't have the requisite coding skills to develop it.
September 08, 2016, 11:07:38 AM
..
How do BIPs work anyway? For instance, if I developed one and thought it would be useful for Bitcoin. What exactly would I do with it?
How do BIPs work anyway? For instance, if I developed one and thought it would be useful for Bitcoin. What exactly would I do with it?
You need to look at BIP 0001 for that answer:
https://en.bitcoin.it/wiki/BIP_0001
However, today there is a convoluted process to test if your BIP is workable. To give it a better than average chance of being accepted, you need to develop some code or pay someone to develop some code along with your reasons for proposing a BIP. If accepted as a BIP you get assigned a BIP number. This doesn't mean a BIP gets accepted and merged into Bitcoin, but its a proposal with merit and might get merged at some future point; which basically means develop your proposal into workable code.
September 08, 2016, 11:03:41 AM
This is how Proof of Bitcoin Node (or any cross chain Node) needs to work, using the OP_RETURN updates in BIP74
The internal communications within the Spreadwallet make this whole thing work. The internal communications within the Spreadwallet can be similar to the way exchanges deal with transactions, they have their own ledgers that keep track of whats going on, and only when customers put money in or take money out do they interact with specific coin daemons.
Because of Bitcoin confirmation wait times, the completion of the proof might take 10 minutes or 10 days, but the relay communications can be ring fenced / locked by the servicenode network to avoid an attacker stealing payments.
If you have the required public and private keys, only you can create and confirm the hash as proof of the broadcast message.
The internal communications within the Spreadwallet make this whole thing work. The internal communications within the Spreadwallet can be similar to the way exchanges deal with transactions, they have their own ledgers that keep track of whats going on, and only when customers put money in or take money out do they interact with specific coin daemons.
Because of Bitcoin confirmation wait times, the completion of the proof might take 10 minutes or 10 days, but the relay communications can be ring fenced / locked by the servicenode network to avoid an attacker stealing payments.
If you have the required public and private keys, only you can create and confirm the hash as proof of the broadcast message.
@Georgem (the real one)
I think we can make Proof of Bitcoin Node work by bringing back PoW into the client.
The validation process to generate an output to the Bitcoin Blockchain, that can be a Hashcash PoW solution, which would do what it was originally intended (before Satoshi got hold of idea) by making the client do work to avoid people spinning up thousands of fake nodes off one server.
September 08, 2016, 11:01:35 AM
I think the issue of bandwidth might be addressed by using similar solutions that logistics firms use.
The largest container ships move huge amounts to ports; ports move containers to trains and trucks; trucks move stuff to regional depots; regional depots push stuff in smaller delivery vans to customers.
Perhaps bitcoin needs a series of 3,000 - 4,000 nodes that are the largest ships; they give priority to data transfer to regional full nodes; these then serve SPV's.
edit
I think we need a BIP.
The largest container ships move huge amounts to ports; ports move containers to trains and trucks; trucks move stuff to regional depots; regional depots push stuff in smaller delivery vans to customers.
Perhaps bitcoin needs a series of 3,000 - 4,000 nodes that are the largest ships; they give priority to data transfer to regional full nodes; these then serve SPV's.
edit
I think we need a BIP.
Would one determine the "largest ships" through a similar coding mechanism as you posted earlier? If you could somehow determine where / how full nodes were being run and how much bandwidth they each have then you could begin to divide them up into classes based on purpose and capability. Very interesting.
It looks like the latest Bitcoin Core releases are starting to feature passing data between specific types of nodes, but for a different purpose. So a BIP on this will be easier
This bit: NO_BLOOM_VERSION
Code:
(strCommand == NetMsgType::FILTERLOAD ||
strCommand == NetMsgType::FILTERADD ||
- strCommand == NetMsgType::FILTERCLEAR))
- {
- if (pfrom->nVersion >= NO_BLOOM_VERSION) {
- LOCK(cs_main);
- Misbehaving(pfrom->GetId(), 100);
- return false;
- } else {
- pfrom->fDisconnect = true;
- return false;
- }
+ strCommand == NetMsgType::FILTERCLEAR)) {
+ LOCK(cs_main);
+ Misbehaving(pfrom->GetId(), 5);
strCommand == NetMsgType::FILTERADD ||
- strCommand == NetMsgType::FILTERCLEAR))
- {
- if (pfrom->nVersion >= NO_BLOOM_VERSION) {
- LOCK(cs_main);
- Misbehaving(pfrom->GetId(), 100);
- return false;
- } else {
- pfrom->fDisconnect = true;
- return false;
- }
+ strCommand == NetMsgType::FILTERCLEAR)) {
+ LOCK(cs_main);
+ Misbehaving(pfrom->GetId(), 5);
https://github.com/bitcoin/bitcoin/pull/8587
How do BIPs work anyway? For instance, if I developed one and thought it would be useful for Bitcoin. What exactly would I do with it?
September 08, 2016, 10:58:22 AM
do i need to "setgenerate true" in the wallet to mine properly or is that just for CPU mining? The GPU miner seems to be working but I'm not sure if that setgenerate was neccessary. I have not yet received any coins but I think its because the GPU keeps cashing every couple of hours. Any help would be cool. I'm brand new to all of this.
Thanks in advance.
Thanks in advance.
I am no expert but I am pretty sure that setgenerate=true means that you are mining with the CPU. As far as the crashing goes - maybe it is a power or update issue in the software?
I think that's right, CPU mining.
Technical support for mining: http://spreadcointalk.org/index.php?board=5.0
I paid a bounty to get this mining video created, so please use it
https://www.youtube.com/watch?v=OhDzpiBLDcA&feature=youtu.be
September 08, 2016, 05:50:07 AM
do i need to "setgenerate true" in the wallet to mine properly or is that just for CPU mining? The GPU miner seems to be working but I'm not sure if that setgenerate was neccessary. I have not yet received any coins but I think its because the GPU keeps cashing every couple of hours. Any help would be cool. I'm brand new to all of this.
Thanks in advance.
Thanks in advance.
I am no expert but I am pretty sure that setgenerate=true means that you are mining with the CPU. As far as the crashing goes - maybe it is a power or update issue in the software?
September 08, 2016, 01:56:33 AM
do i need to "setgenerate true" in the wallet to mine properly or is that just for CPU mining? The GPU miner seems to be working but I'm not sure if that setgenerate was neccessary. I have not yet received any coins but I think its because the GPU keeps cashing every couple of hours. Any help would be cool. I'm brand new to all of this.
Thanks in advance.
Thanks in advance.
September 07, 2016, 11:03:01 PM
I think the issue of bandwidth might be addressed by using similar solutions that logistics firms use.
The largest container ships move huge amounts to ports; ports move containers to trains and trucks; trucks move stuff to regional depots; regional depots push stuff in smaller delivery vans to customers.
Perhaps bitcoin needs a series of 3,000 - 4,000 nodes that are the largest ships; they give priority to data transfer to regional full nodes; these then serve SPV's.
edit
I think we need a BIP.
The largest container ships move huge amounts to ports; ports move containers to trains and trucks; trucks move stuff to regional depots; regional depots push stuff in smaller delivery vans to customers.
Perhaps bitcoin needs a series of 3,000 - 4,000 nodes that are the largest ships; they give priority to data transfer to regional full nodes; these then serve SPV's.
edit
I think we need a BIP.
Would one determine the "largest ships" through a similar coding mechanism as you posted earlier? If you could somehow determine where / how full nodes were being run and how much bandwidth they each have then you could begin to divide them up into classes based on purpose and capability. Very interesting.
It looks like the latest Bitcoin Core releases are starting to feature passing data between specific types of nodes, but for a different purpose. So a BIP on this will be easier
This bit: NO_BLOOM_VERSION
Code:
(strCommand == NetMsgType::FILTERLOAD ||
strCommand == NetMsgType::FILTERADD ||
- strCommand == NetMsgType::FILTERCLEAR))
- {
- if (pfrom->nVersion >= NO_BLOOM_VERSION) {
- LOCK(cs_main);
- Misbehaving(pfrom->GetId(), 100);
- return false;
- } else {
- pfrom->fDisconnect = true;
- return false;
- }
+ strCommand == NetMsgType::FILTERCLEAR)) {
+ LOCK(cs_main);
+ Misbehaving(pfrom->GetId(), 5);
strCommand == NetMsgType::FILTERADD ||
- strCommand == NetMsgType::FILTERCLEAR))
- {
- if (pfrom->nVersion >= NO_BLOOM_VERSION) {
- LOCK(cs_main);
- Misbehaving(pfrom->GetId(), 100);
- return false;
- } else {
- pfrom->fDisconnect = true;
- return false;
- }
+ strCommand == NetMsgType::FILTERCLEAR)) {
+ LOCK(cs_main);
+ Misbehaving(pfrom->GetId(), 5);
https://github.com/bitcoin/bitcoin/pull/8587
September 07, 2016, 02:41:10 PM
Super Hydra troll
In time you'll look back at your contribution to Bitcoin and how it empowers societies, and you'll realise what a fool you were and regret your missed opportunities to make a positive impact.
September 07, 2016, 12:10:56 AM
...
Hydra Troll
Hydra Troll
Hydra Troll
Super solid dev
Hydra TrollLooks like Hydra have infiltrated SpreadBitcoin
georgerm here.... I apologize that I haven't been onlinee as much. I have had to keep my use of technology secret from my tribe. If they knew that I was using technology, I would surely take the L. They don't even know that I have a computer. I must keep the followin g truncated
Been trapped here for a while now. Somehow I was knocked unconscious and when I woke up I was in a giant anarcho primitivist tribe. the past few months have been trying on my soul.... If any of the members of the tribe found out that I was here typing on my computer, I would surely be stoned, pickled, and fed to the commune......Usually tribes feed people to the dogs, but primitivists think dogs are technology.
Regardless of how the anprims would deal with me, development may be slow from here on out due to this sole, yet very large issue. Please send any penicillin you may have. I have a nasty toe infection and if it doesn't go away I don't know if I'll ever be able to finish the half - address vanity generator.
Stay tuned.
September 06, 2016, 06:27:03 PM
I think the issue of bandwidth might be addressed by using similar solutions that logistics firms use.
The largest container ships move huge amounts to ports; ports move containers to trains and trucks; trucks move stuff to regional depots; regional depots push stuff in smaller delivery vans to customers.
Perhaps bitcoin needs a series of 3,000 - 4,000 nodes that are the largest ships; they give priority to data transfer to regional full nodes; these then serve SPV's.
edit
I think we need a BIP.
The largest container ships move huge amounts to ports; ports move containers to trains and trucks; trucks move stuff to regional depots; regional depots push stuff in smaller delivery vans to customers.
Perhaps bitcoin needs a series of 3,000 - 4,000 nodes that are the largest ships; they give priority to data transfer to regional full nodes; these then serve SPV's.
edit
I think we need a BIP.
Would one determine the "largest ships" through a similar coding mechanism as you posted earlier? If you could somehow determine where / how full nodes were being run and how much bandwidth they each have then you could begin to divide them up into classes based on purpose and capability. Very interesting.
You can get quite a lot of useful information passing between nodes:
Code:
"id": n, (numeric) Peer index
"addr":"host:port", (string) The ip address and port of the peer
"addrlocal":"ip:port", (string) local address
"services":"xxxxxxxxxxxxxxxx", (string) The services offered
"lastsend": ttt, (numeric) The time in seconds since epoch (Jan 1 1970 GMT) of the last send
"lastrecv": ttt, (numeric) The time in seconds since epoch (Jan 1 1970 GMT) of the last receive
"bytessent": n, (numeric) The total bytes sent
"bytesrecv": n, (numeric) The total bytes received
"conntime": ttt, (numeric) The connection time in seconds since epoch (Jan 1 1970 GMT)
"timeoffset": ttt (numeric) The time offset in seconds
"pingtime": n, (numeric) ping time
"pingwait": n, (numeric) ping wait
"version": v (numeric) The peer version, such as 7001
"subver": "/Satoshi:0.8.5/", (string) The string version
"inbound": true|false, (boolean) Inbound (true) or Outbound (false)
"startingheight": n, (numeric) The starting height (block) of the peer
"banscore": n, (numeric) The ban score
"synced_headers": n, (numeric) The last header we have in common with this peer
"synced_blocks": n, (numeric) The last block we have in common with this peer
"inflight":n, (numeric) The heights of blocks we're currently asking from this peer
"addr":"host:port", (string) The ip address and port of the peer
"addrlocal":"ip:port", (string) local address
"services":"xxxxxxxxxxxxxxxx", (string) The services offered
"lastsend": ttt, (numeric) The time in seconds since epoch (Jan 1 1970 GMT) of the last send
"lastrecv": ttt, (numeric) The time in seconds since epoch (Jan 1 1970 GMT) of the last receive
"bytessent": n, (numeric) The total bytes sent
"bytesrecv": n, (numeric) The total bytes received
"conntime": ttt, (numeric) The connection time in seconds since epoch (Jan 1 1970 GMT)
"timeoffset": ttt (numeric) The time offset in seconds
"pingtime": n, (numeric) ping time
"pingwait": n, (numeric) ping wait
"version": v (numeric) The peer version, such as 7001
"subver": "/Satoshi:0.8.5/", (string) The string version
"inbound": true|false, (boolean) Inbound (true) or Outbound (false)
"startingheight": n, (numeric) The starting height (block) of the peer
"banscore": n, (numeric) The ban score
"synced_headers": n, (numeric) The last header we have in common with this peer
"synced_blocks": n, (numeric) The last block we have in common with this peer
"inflight":n, (numeric) The heights of blocks we're currently asking from this peer
This can tell you the regional demand, if you have a mechanism to collect aggregated data and use it to host nodes locally to where the SPV demand is highest. This would help a lot as nodes like to connect to peers that are able to serve up data the quickest.
What I think we need is a priority system. Maybe:
* If you're an SPV get your data from full nodes and only from full nodes.
* If you're a node set to pruning, get your data only from full nodes.
* If you're a full node connect to other full nodes, but get most of your data from ServiceNodes.
* If you're a full node hosted by a ServiceNode, connect to other ServiceNodes to hold and sync a copy of the full blockchain, and ignore SPV's.
Needs to be thought through a lot better.
September 06, 2016, 06:04:18 PM
I think the issue of bandwidth might be addressed by using similar solutions that logistics firms use.
The largest container ships move huge amounts to ports; ports move containers to trains and trucks; trucks move stuff to regional depots; regional depots push stuff in smaller delivery vans to customers.
Perhaps bitcoin needs a series of 3,000 - 4,000 nodes that are the largest ships; they give priority to data transfer to regional full nodes; these then serve SPV's.
edit
I think we need a BIP.
The largest container ships move huge amounts to ports; ports move containers to trains and trucks; trucks move stuff to regional depots; regional depots push stuff in smaller delivery vans to customers.
Perhaps bitcoin needs a series of 3,000 - 4,000 nodes that are the largest ships; they give priority to data transfer to regional full nodes; these then serve SPV's.
edit
I think we need a BIP.
Would one determine the "largest ships" through a similar coding mechanism as you posted earlier? If you could somehow determine where / how full nodes were being run and how much bandwidth they each have then you could begin to divide them up into classes based on purpose and capability. Very interesting.
Jump to: