Bitcoin Forum
September 20, 2020, 11:24:06 AM *
News: Latest Bitcoin Core release: 0.20.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 [169] 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 ... 1117 »
  Print  
Author Topic: Obyte: Totally new consensus algorithm + private untraceable payments  (Read 1218030 times)
drays
Legendary
*
Offline Offline

Activity: 2002
Merit: 1029


View Profile
January 12, 2017, 01:54:30 AM
 #3361

Sorry if this sounds lame (I admit I didn't read the whole whitepaper Grin), but is there any way to see in block explorer or anywhere else, the date/time when a transaction is actually made!?  Huh

... this space is not for rent ...
1600601046
Hero Member
*
Offline Offline

Posts: 1600601046

View Profile Personal Message (Offline)

Ignore
1600601046
Reply with quote  #2

1600601046
Report to moderator
1600601046
Hero Member
*
Offline Offline

Posts: 1600601046

View Profile Personal Message (Offline)

Ignore
1600601046
Reply with quote  #2

1600601046
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1600601046
Hero Member
*
Offline Offline

Posts: 1600601046

View Profile Personal Message (Offline)

Ignore
1600601046
Reply with quote  #2

1600601046
Report to moderator
1600601046
Hero Member
*
Offline Offline

Posts: 1600601046

View Profile Personal Message (Offline)

Ignore
1600601046
Reply with quote  #2

1600601046
Report to moderator
1600601046
Hero Member
*
Offline Offline

Posts: 1600601046

View Profile Personal Message (Offline)

Ignore
1600601046
Reply with quote  #2

1600601046
Report to moderator
CryptKeeper
Legendary
*
Offline Offline

Activity: 1992
Merit: 1026


bitcoin and altcoin enthusiast


View Profile WWW
January 12, 2017, 02:01:40 AM
 #3362

Sorry if this sounds lame (I admit I didn't read the whole whitepaper Grin), but is there any way to see in block explorer or anywhere else, the date/time when a transaction is actually made!?  Huh

Look in the wallet at the "History" tab, then click on a tx to see the details.

Follow me on twitter for the latest news on bitcoin and altcoins and I'll follow you back the same day!
Obyte - An open cryptocurrency platform ready for real world adoption
drays
Legendary
*
Offline Offline

Activity: 2002
Merit: 1029


View Profile
January 12, 2017, 02:04:57 AM
Last edit: January 12, 2017, 03:11:48 AM by drays
 #3363

Sorry if this sounds lame (I admit I didn't read the whole whitepaper Grin), but is there any way to see in block explorer or anywhere else, the date/time when a transaction is actually made!?  Huh

Look in the wallet at the "History" tab, then click on a tx to see the details.

Ok, thanks. But I meant the transactions made by others (not from/to my wallet) Smiley
Is there any way to see the timestamps on them?

... this space is not for rent ...
Dynamic Index
Member
**
Offline Offline

Activity: 83
Merit: 10


View Profile
January 12, 2017, 03:09:33 AM
 #3364

So before the supposed snapshot in med February, would it be more profitable to buy bytes of exchange and store in wallet (will simply storing the byte in wallet gain byte at snapchat)?

Or to link BTC address and gain byte that way

Let's assume with the same amount of bitcoin that you would be buying byte with or linking.
yvv
Legendary
*
Offline Offline

Activity: 1344
Merit: 1000

.


View Profile WWW
January 12, 2017, 03:36:59 AM
 #3365

So before the supposed snapshot in med February, would it be more profitable to buy bytes of exchange and store in wallet (will simply storing the byte in wallet gain byte at snapchat)?

Or to link BTC address and gain byte that way

Let's assume with the same amount of bitcoin that you would be buying byte with or linking.

Just do your math bro Smiley During next giveaway, 1BTC gives you 62.5Mb, the same amount as 625Mb gives you. So, if bytes are cheaper than 625Mb per BTC, it is better to buy bytes with BTC, otherwise sell bytes to have more BTC.

.
Dynamic Index
Member
**
Offline Offline

Activity: 83
Merit: 10


View Profile
January 12, 2017, 03:44:03 AM
 #3366

So before the supposed snapshot in med February, would it be more profitable to buy bytes of exchange and store in wallet (will simply storing the byte in wallet gain byte at snapchat)?

Or to link BTC address and gain byte that way

Let's assume with the same amount of bitcoin that you would be buying byte with or linking.

Just do your math bro Smiley During next giveaway, 1BTC gives you 62.5Mb, the same amount as 625Mb gives you. So, if bytes are cheaper than 625Mb per BTC, it is better to buy bytes with BTC, otherwise sell bytes to have more BTC.


What if I were to take a bank loan out for lets say one month of $50,000 and buy 62 bitcoin. Then I wait until snapshot, verify bitcoin address, receive Mb, then sell bitcoin to pay back loan?
Dynamic Index
Member
**
Offline Offline

Activity: 83
Merit: 10


View Profile
January 12, 2017, 03:47:35 AM
 #3367

Okay a serious question:  What's the best way to backup wallet?  I wrote down restore phrase and wrote down encryption key.  Do I need to backup anything else?  I couldn't find a wallet.dat in application support (mac)
CryptKeeper
Legendary
*
Offline Offline

Activity: 1992
Merit: 1026


bitcoin and altcoin enthusiast


View Profile WWW
January 12, 2017, 04:04:17 AM
 #3368

Okay a serious question:  What's the best way to backup wallet?  I wrote down restore phrase and wrote down encryption key.  Do I need to backup anything else?  I couldn't find a wallet.dat in application support (mac)

FYI

Quote
Byteball Backups and Recovery

Byteball uses a single extended private key for all wallets, BIP44 is used for wallet address derivation. There is a BIP39 mnemonic for backing up the wallet key, but it is not enough. Private payments and co-signers of multisig wallets are stored only in the app's data directory, which you have to back up manually:

macOS: ~/Library/Application Support/byteball
Linux: ~/.config/byteball
Windows: %LOCALAPPDATA%\byteball

Follow me on twitter for the latest news on bitcoin and altcoins and I'll follow you back the same day!
Obyte - An open cryptocurrency platform ready for real world adoption
jwinterm
Legendary
*
Offline Offline

Activity: 2394
Merit: 1070



View Profile
January 12, 2017, 04:17:37 AM
 #3369

CryptKeeper, are you and how much are you getting paid to run this thread? Are there other people on "the team" getting compensated? Where's the money coming to pay people, presuming people are getting paid?
Dynamic Index
Member
**
Offline Offline

Activity: 83
Merit: 10


View Profile
January 12, 2017, 04:32:29 AM
 #3370

Okay a serious question:  What's the best way to backup wallet?  I wrote down restore phrase and wrote down encryption key.  Do I need to backup anything else?  I couldn't find a wallet.dat in application support (mac)

FYI

Quote
Byteball Backups and Recovery

Byteball uses a single extended private key for all wallets, BIP44 is used for wallet address derivation. There is a BIP39 mnemonic for backing up the wallet key, but it is not enough. Private payments and co-signers of multisig wallets are stored only in the app's data directory, which you have to back up manually:

macOS: ~/Library/Application Support/byteball
Linux: ~/.config/byteball
Windows: %LOCALAPPDATA%\byteball

Is this data encrypted?  I'm about to store on secure cloud account.
Espo
Newbie
*
Offline Offline

Activity: 37
Merit: 0


View Profile
January 12, 2017, 05:45:28 AM
 #3371

Okay a serious question:  What's the best way to backup wallet?  I wrote down restore phrase and wrote down encryption key.  Do I need to backup anything else?  I couldn't find a wallet.dat in application support (mac)

FYI

Quote
Byteball Backups and Recovery

Byteball uses a single extended private key for all wallets, BIP44 is used for wallet address derivation. There is a BIP39 mnemonic for backing up the wallet key, but it is not enough. Private payments and co-signers of multisig wallets are stored only in the app's data directory, which you have to back up manually:

macOS: ~/Library/Application Support/byteball
Linux: ~/.config/byteball
Windows: %LOCALAPPDATA%\byteball

Is this data encrypted?  I'm about to store on secure cloud account.

No, You should ZIP/RAR the files with a strong Password.
WorldCoiner
Hero Member
*****
Offline Offline

Activity: 1069
Merit: 681



View Profile WWW
January 12, 2017, 07:47:11 AM
 #3372

CryptKeeper, are you and how much are you getting paid to run this thread? Are there other people on "the team" getting compensated? Where's the money coming to pay people, presuming people are getting paid?

Cryptkeeper is just a nice guy and community member, that did this purely out of altruistic reasons.
To be honest, me supporting Byteball also without small financial benefit (during the distribution I have had 3.5 BTC, really not a Byteball whale at all).
But I like Tony and I’m really impressed what he was able the achieve in such a short timeframe. Especially I focus always at new technology and the DAG can be the revolution of Cryptocurrency. It's in my view really a new generation, the third one.

There is at the moment no money at the table. Just the value of the Byteball we have received through the distribution can be lifted.
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2128
Merit: 1009

Newbie


View Profile
January 12, 2017, 08:31:29 AM
 #3373

This explains why there is no a protection against an eclipse attack, which can be conducted if a naive peer discovery is used (which is the case of Byteball, I noticed this trying to recover byteballs of my friend). In IOTA necessity to talk to people is an anti-Sybil measure. Poor SatoNatomato doesn't understand all these nuances, I suggest to forgive his childishness.

For the record, peer discovery is irrelevant to consensus in Byteball.  Even if Sybiled, a node cannot select a wrong branch, by design.  The worst that can happen to a node while it is Sybiled, is that the node will stay stuck at some old point on the DAG, as if it were offline.  CfB if you want to reply, IOTA thread is not the best place for in-depth discussion of Byteball, post to https://bitcointalk.org/index.php?topic=1608859.0.

This is an attack that came to my mind while I was reading the source code trying to get what "device ID" was for:

The whitepaper says:
Quote
There is no partial order between them. In this case, we accept both. We establish a total order between the units later on, when they are buried deep enough under newer units (see below how we do it). The one that appears earlier on the total order is deemed valid, while the other is deemed invalid.
Quote
In normal use, people mostly link their new units to slightly less recent units, meaning that the DAG grows only in one direction.

The former allows to trick a user into believing that he received coins (if we can censor the traffic). The latter allows to make the others extend a branch we need (if we can (to some extent) censor the global traffic).

Imagine that I have poisoned the network and 90% of the nodes (not physical machines, just IPs) are controlled by me. What stops me from scamming a merchant in such way:

1. Issue a payment to the merchant and a payment to myself with "no partial order between them"
2. Make the others to prioritize the payment to myself (the branch with the payment to merchants will be extend too and this is the only transactions the merchant will see)
3. Get the purchased item delivered
4. Stop the attack, my payment is already considered as a part of the main chain, let the merchant to see that his payment is not.
kaicrypzen
Hero Member
*****
Offline Offline

Activity: 1092
Merit: 653



View Profile
January 12, 2017, 09:10:44 AM
 #3374

Is there a trading thread?

Yes there is: https://bitcointalk.org/index.php?topic=1728405. You can also trade on Slack: https://byteball.slack.com, check the channels #trading, #book, #auctionroom and #trading_blackbyte.

coinhugger
Hero Member
*****
Offline Offline

Activity: 728
Merit: 500



View Profile
January 12, 2017, 10:00:25 AM
 #3375

This explains why there is no a protection against an eclipse attack, which can be conducted if a naive peer discovery is used (which is the case of Byteball, I noticed this trying to recover byteballs of my friend). In IOTA necessity to talk to people is an anti-Sybil measure. Poor SatoNatomato doesn't understand all these nuances, I suggest to forgive his childishness.

For the record, peer discovery is irrelevant to consensus in Byteball.  Even if Sybiled, a node cannot select a wrong branch, by design.  The worst that can happen to a node while it is Sybiled, is that the node will stay stuck at some old point on the DAG, as if it were offline.  CfB if you want to reply, IOTA thread is not the best place for in-depth discussion of Byteball, post to https://bitcointalk.org/index.php?topic=1608859.0.

This is an attack that came to my mind while I was reading the source code trying to get what "device ID" was for:

The whitepaper says:
Quote
There is no partial order between them. In this case, we accept both. We establish a total order between the units later on, when they are buried deep enough under newer units (see below how we do it). The one that appears earlier on the total order is deemed valid, while the other is deemed invalid.
Quote
In normal use, people mostly link their new units to slightly less recent units, meaning that the DAG grows only in one direction.

The former allows to trick a user into believing that he received coins (if we can censor the traffic). The latter allows to make the others extend a branch we need (if we can (to some extent) censor the global traffic).

Imagine that I have poisoned the network and 90% of the nodes (not physical machines, just IPs) are controlled by me. What stops me from scamming a merchant in such way:

1. Issue a payment to the merchant and a payment to myself with "no partial order between them"
2. Make the others to prioritize the payment to myself (the branch with the payment to merchants will be extend too and this is the only transactions the merchant will see)
3. Get the purchased item delivered
4. Stop the attack, my payment is already considered as a part of the main chain, let the merchant to see that his payment is not.


This is a scary thought. I hope the developer can mitigate this potential vulnerability if the above-mentioned procedure really works.

tonych
Hero Member
*****
Offline Offline

Activity: 903
Merit: 863


View Profile WWW
January 12, 2017, 10:28:30 AM
 #3376

Sorry if this sounds lame (I admit I didn't read the whole whitepaper Grin), but is there any way to see in block explorer or anywhere else, the date/time when a transaction is actually made!?  Huh

Look in the wallet at the "History" tab, then click on a tx to see the details.

Ok, thanks. But I meant the transactions made by others (not from/to my wallet) Smiley
Is there any way to see the timestamps on them?

There are no timestamps in Byteball protocol, they are just not needed.  That's why there are no reliable timestamps.  The ones you see in History tab are the times and dates when your wallet first learnt about the transaction (or, if you are on light wallet, when the light vendor first learnt about the tx).

Simplicity is beauty
SatoNatomato
Sr. Member
****
Offline Offline

Activity: 378
Merit: 250


View Profile
January 12, 2017, 10:36:15 AM
 #3377

This explains why there is no a protection against an eclipse attack, which can be conducted if a naive peer discovery is used (which is the case of Byteball, I noticed this trying to recover byteballs of my friend). In IOTA necessity to talk to people is an anti-Sybil measure. Poor SatoNatomato doesn't understand all these nuances, I suggest to forgive his childishness.

For the record, peer discovery is irrelevant to consensus in Byteball.  Even if Sybiled, a node cannot select a wrong branch, by design.  The worst that can happen to a node while it is Sybiled, is that the node will stay stuck at some old point on the DAG, as if it were offline.  CfB if you want to reply, IOTA thread is not the best place for in-depth discussion of Byteball, post to https://bitcointalk.org/index.php?topic=1608859.0.

This is an attack that came to my mind while I was reading the source code trying to get what "device ID" was for:

The whitepaper says:
Quote
There is no partial order between them. In this case, we accept both. We establish a total order between the units later on, when they are buried deep enough under newer units (see below how we do it). The one that appears earlier on the total order is deemed valid, while the other is deemed invalid.
Quote
In normal use, people mostly link their new units to slightly less recent units, meaning that the DAG grows only in one direction.

The former allows to trick a user into believing that he received coins (if we can censor the traffic). The latter allows to make the others extend a branch we need (if we can (to some extent) censor the global traffic).

Imagine that I have poisoned the network and 90% of the nodes (not physical machines, just IPs) are controlled by me. What stops me from scamming a merchant in such way:

1. Issue a payment to the merchant and a payment to myself with "no partial order between them"
2. Make the others to prioritize the payment to myself (the branch with the payment to merchants will be extend too and this is the only transactions the merchant will see)
3. Get the purchased item delivered
4. Stop the attack, my payment is already considered as a part of the main chain, let the merchant to see that his payment is not.


This is a scary thought. I hope the developer can mitigate this potential vulnerability if the above-mentioned procedure really works.


Its bull and FUD, which CFB would have known if he actually read the whitepaper.

This is what witnesses are for, the payment is not Finaluzed as Confirmed unless a witness sees it, which in the scenario doesnt happen. Its the same dumb attack as sending a goods after no confirmations in bitcoin.
tonych
Hero Member
*****
Offline Offline

Activity: 903
Merit: 863


View Profile WWW
January 12, 2017, 10:46:07 AM
 #3378

This explains why there is no a protection against an eclipse attack, which can be conducted if a naive peer discovery is used (which is the case of Byteball, I noticed this trying to recover byteballs of my friend). In IOTA necessity to talk to people is an anti-Sybil measure. Poor SatoNatomato doesn't understand all these nuances, I suggest to forgive his childishness.

For the record, peer discovery is irrelevant to consensus in Byteball.  Even if Sybiled, a node cannot select a wrong branch, by design.  The worst that can happen to a node while it is Sybiled, is that the node will stay stuck at some old point on the DAG, as if it were offline.  CfB if you want to reply, IOTA thread is not the best place for in-depth discussion of Byteball, post to https://bitcointalk.org/index.php?topic=1608859.0.

This is an attack that came to my mind while I was reading the source code trying to get what "device ID" was for:

The whitepaper says:
Quote
There is no partial order between them. In this case, we accept both. We establish a total order between the units later on, when they are buried deep enough under newer units (see below how we do it). The one that appears earlier on the total order is deemed valid, while the other is deemed invalid.
Quote
In normal use, people mostly link their new units to slightly less recent units, meaning that the DAG grows only in one direction.

The former allows to trick a user into believing that he received coins (if we can censor the traffic). The latter allows to make the others extend a branch we need (if we can (to some extent) censor the global traffic).

Imagine that I have poisoned the network and 90% of the nodes (not physical machines, just IPs) are controlled by me. What stops me from scamming a merchant in such way:

1. Issue a payment to the merchant and a payment to myself with "no partial order between them"
2. Make the others to prioritize the payment to myself (the branch with the payment to merchants will be extend too and this is the only transactions the merchant will see)
3. Get the purchased item delivered
4. Stop the attack, my payment is already considered as a part of the main chain, let the merchant to see that his payment is not.

If the user waits that the transaction is final, he cannot be defrauded.
In your example, you isolate the merchant from the real network and feed him with a fake branch.  The merchant will accept your units and add them to his version of the DAG, but since there are no witness-authored units on your branch, it will not move the stability point forward and your double-spent payment will stay unconfirmed for as long as your attack continues.  Number of nodes is totally irrelevant, it is the presence of witnesses what makes a branch real.

Simplicity is beauty
coinhugger
Hero Member
*****
Offline Offline

Activity: 728
Merit: 500



View Profile
January 12, 2017, 10:57:03 AM
Last edit: January 12, 2017, 11:09:41 AM by coinhugger
 #3379

This explains why there is no a protection against an eclipse attack, which can be conducted if a naive peer discovery is used (which is the case of Byteball, I noticed this trying to recover byteballs of my friend). In IOTA necessity to talk to people is an anti-Sybil measure. Poor SatoNatomato doesn't understand all these nuances, I suggest to forgive his childishness.

For the record, peer discovery is irrelevant to consensus in Byteball.  Even if Sybiled, a node cannot select a wrong branch, by design.  The worst that can happen to a node while it is Sybiled, is that the node will stay stuck at some old point on the DAG, as if it were offline.  CfB if you want to reply, IOTA thread is not the best place for in-depth discussion of Byteball, post to https://bitcointalk.org/index.php?topic=1608859.0.

This is an attack that came to my mind while I was reading the source code trying to get what "device ID" was for:

The whitepaper says:
Quote
There is no partial order between them. In this case, we accept both. We establish a total order between the units later on, when they are buried deep enough under newer units (see below how we do it). The one that appears earlier on the total order is deemed valid, while the other is deemed invalid.
Quote
In normal use, people mostly link their new units to slightly less recent units, meaning that the DAG grows only in one direction.

The former allows to trick a user into believing that he received coins (if we can censor the traffic). The latter allows to make the others extend a branch we need (if we can (to some extent) censor the global traffic).

Imagine that I have poisoned the network and 90% of the nodes (not physical machines, just IPs) are controlled by me. What stops me from scamming a merchant in such way:

1. Issue a payment to the merchant and a payment to myself with "no partial order between them"
2. Make the others to prioritize the payment to myself (the branch with the payment to merchants will be extend too and this is the only transactions the merchant will see)
3. Get the purchased item delivered
4. Stop the attack, my payment is already considered as a part of the main chain, let the merchant to see that his payment is not.

If the user waits that the transaction is final, he cannot be defrauded.
In your example, you isolate the merchant from the real network and feed him with a fake branch.  The merchant will accept your units and add them to his version of the DAG, but since there are no witness-authored units on your branch, it will not move the stability point forward and your double-spent payment will stay unconfirmed for as long as your attack continues.  Number of nodes is totally irrelevant, it is the presence of witnesses what makes a branch real.

@Tonych, thanks for clearing that up. Nothing to worry about then. Keep up the good work!

 
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2128
Merit: 1009

Newbie


View Profile
January 12, 2017, 11:02:27 AM
 #3380

If the user waits that the transaction is final, he cannot be defrauded.
In your example, you isolate the merchant from the real network and feed him with a fake branch.  The merchant will accept your units and add them to his version of the DAG, but since there are no witness-authored units on your branch, it will not move the stability point forward and your double-spent payment will stay unconfirmed for as long as your attack continues.  Number of nodes is totally irrelevant, it is the presence of witnesses what makes a branch real.

Great, I hope now SatoNatomato sees why IOTA couldn't use the same method of peer discovery.
Pages: « 1 ... 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 [169] 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 ... 1117 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!