Bitcoin Forum
January 19, 2019, 07:31:54 AM *
News: Latest Bitcoin Core release: 0.17.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 [988] 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 ... 2030 »
  Print  
Author Topic: [XMR] Monero - A secure, private, untraceable cryptocurrency  (Read 4531120 times)
Hueristic
Legendary
*
Offline Offline

Activity: 1876
Merit: 1121


Doomed to see the future and unable to prevent it


View Profile
February 09, 2015, 04:23:21 AM
 #19741

///

I have a House, a car, a good job a wife and 2 children. I think i am rich!!///

You are! Smiley

BITSLER                 ▄███
               ▄████▀
             ▄████▀
           ▄████▀  ▄██▄
         ▄████▀    ▀████▄
       ▄████▀        ▀████▄
     ▄████▀            ▀████▄
   ▄████▀                ▀████▄
 ▄████▀ ▄████▄      ▄████▄ ▀████▄
█████   ██████      ██████   █████
 ▀████▄ ▀████▀      ▀████▀ ▄████▀
   ▀████▄                ▄████▀
     ▀████▄            ▄████▀
       ▀████▄        ▄████▀
         ▀████▄    ▄████▀
           ▀████▄▄████▀
             ▀██████▀
               ▀▀▀▀
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▄            
▄▄▄▄▀▀▀▀    ▄▄█▄▄ ▀▀▄         
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▄      
█  ▀▄▄  ▀█▀▀ ▄      ▀████   ▀▀▄   
█ █▄  ▀▄   ▀████       ▀▀ ▄██▄ ▀▀▄
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
█  ▀▀       ▀▄▄ ▀████      ▄▄▄▀▀▀  █
█            ▄ ▀▄    ▄▄▄▀▀▀   ▄▄  █
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
█ ▄▄   ███   ▀██  █           ▀▀  █ 
█ ███  ▀██       █        ▄▄      █ 
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀  
▀▄            █        ▀▀      █  
▀▀▄   ███▄  █   ▄▄          █   
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀    
▀▀▄   █   ▀▀▄▄▄▀▀▀         
▄▄▄▄▄▄▄▄▄▄▄█▄▄▀▀▀▀              
              ▄▄▄██████▄▄▄
          ▄▄████████████████▄▄
        ▄██████▀▀▀▀▀▀▀▀▀▀██████▄
▄     ▄█████▀             ▀█████▄
██▄▄ █████▀                ▀█████
 ████████            ▄██      █████
  ████████▄         ███▀       ████▄
  █████████▀▀     ▄███▀        █████
   █▀▀▀          █████         █████
     ▄▄▄         ████          █████
   █████          ▀▀           ████▀
    █████                     █████
     █████▄                 ▄█████
      ▀█████▄             ▄█████▀
        ▀██████▄▄▄▄▄▄▄▄▄▄██████▀
          ▀▀████████████████▀▀
              ▀▀▀██████▀▀▀
            ▄▄▄███████▄▄▄
         ▄█▀▀▀ ▄▄▄▄▄▄▄ ▀▀▀█▄
       █▀▀ ▄█████████████▄ ▀▀█
     █▀▀ ███████████████████ ▀▀█
    █▀ ███████████████████████ ▀█
   █▀ ███████████████▀▀ ███████ ▀█
 ▄█▀ ██████████████▀      ▀█████ ▀█▄
███ ███████████▀▀            ▀▀██ ███
███ ███████▀▀                     ███
███ ▀▀▀▀                          ███
▀██▄                             ▄██▀
  ▀█▄                            ▀▀
    █▄       █▄▄▄▄▄▄▄▄▄█
     █▄      ▀█████████▀
      ▀█▄      ▀▀▀▀▀▀▀
        ▀▀█▄▄  ▄▄▄
            ▀▀█████
[]
"If you don't want people to know you're a scumbag then don't be a scumbag." -- margaritahuyan
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1547883114
Hero Member
*
Offline Offline

Posts: 1547883114

View Profile Personal Message (Offline)

Ignore
1547883114
Reply with quote  #2

1547883114
Report to moderator
1547883114
Hero Member
*
Offline Offline

Posts: 1547883114

View Profile Personal Message (Offline)

Ignore
1547883114
Reply with quote  #2

1547883114
Report to moderator
1547883114
Hero Member
*
Offline Offline

Posts: 1547883114

View Profile Personal Message (Offline)

Ignore
1547883114
Reply with quote  #2

1547883114
Report to moderator
fluffypony
Donator
Legendary
*
Offline Offline

Activity: 1260
Merit: 1024


GetMonero.org / MyMonero.com


View Profile WWW
February 09, 2015, 12:25:26 PM
 #19742

fluffypony, had you noticed my post about sophia database?

http://sphia.org/

If yes, please write few words what do you think about.

Sophia was one of the embedded databases we initially considered, but ultimately went for LMDB because it is better suited to our workloads (based on casual observation, it was impossible to test that theory at that stage;)

Ultimately we aren't preventing anyone from writing an additional implementation and submitting a PR, and we will at the very least have a BerkleyDB fall-back implementation for environments that don't play well with large MMAPs.

fluffypony
Donator
Legendary
*
Offline Offline

Activity: 1260
Merit: 1024


GetMonero.org / MyMonero.com


View Profile WWW
February 09, 2015, 12:29:54 PM
 #19743

I see one use of multiple addresses: when you don't want to know that two transactions go to the same address (like if you don't want people to find you by googling your address which is on bitcointalk signature of profile, or openalias, for instance).
But since there is no much of these needs, you may as well just use a second wallet.

It doesn't matter if your address is known, as it's impossible (with our current cryptography) to analyse the blockchain and find transactions you were involved in. Even if that was possible it still wouldn't be disastrous, as all that can be observed are transactions you *may or may not* have been involved in (thanks to ring signatures). The only time multiple wallets are necessary are for separating your personal and business accounts, for instance, or for a company that wants each department to have its own address and accounts.

matrix961
Full Member
***
Offline Offline

Activity: 150
Merit: 100


View Profile
February 09, 2015, 01:20:16 PM
 #19744

Just wanted to say that using mymonero.com has been really awesome. It's been working extremely well and has made it much easier to use monero.

I donated 40 xmr to the dev address. I know it's not much but it's what I can do for now. Smiley
Bavaria
Hero Member
*****
Offline Offline

Activity: 997
Merit: 502



View Profile
February 09, 2015, 01:26:15 PM
 #19745

Any progress in Monero based market plan?

          ██
          ███
          ████
         ██████
        ▄███████
       ▄████████
      ▄█████████
     ██████████
    ██████████    ██
   ██████████     ███
  ██████████     █████
 ██████████     ██████▄
 █████████     ████████
█████████     █████████
████████     ██████████
████████    ███████████
 ███████    ██████████
  ██████    █████████
   ▀█████    ██████▀
     ▀▀███    ██▀▀
 
Huobi Russia
 

|
  Exchange Trading
OTC / Mining pool
Listing new projects
Innovations Development
  High Security / Support 24/7
Special security for traders
App for IOS and Android
Dedicated high-speed API
 

|
 
.PRIVATE SALE.
STARTS 10.12.2018
 
.PUBLIC SALE.
STARTS 08.04.2019
   

|
  ENG| RU ● ●  ———
ANN THREAD
  FACEBOOK
REDDIT
TELEGRAM
TWITTER
fluffypony
Donator
Legendary
*
Offline Offline

Activity: 1260
Merit: 1024


GetMonero.org / MyMonero.com


View Profile WWW
February 09, 2015, 01:45:12 PM
 #19746

Code:
get_bulk_payments(json_encode(array('min_block_height'=>399206)));

When can we expect this function to work with only min_block_height parameter in the pre-built libraries?

That's not really on our radar; get_bulk_payments is for scanning payment IDs you already know. A general scan of the wallet would be using the incoming_transfers call.

MoneroMooo
Legendary
*
Offline Offline

Activity: 1280
Merit: 1001


View Profile
February 09, 2015, 01:59:02 PM
 #19747

Code:
get_bulk_payments(json_encode(array('min_block_height'=>399206)));

When can we expect this function to work with only min_block_height parameter in the pre-built libraries?

That's not really on our radar; get_bulk_payments is for scanning payment IDs you already know. A general scan of the wallet would be using the incoming_transfers call.

get_bulk_payments does give information like block height/payment id for the incoming tx (which you want to know if you want to wait for N confirmations before crediting), and has a min_block_height which hte other doesn't. So using incoming_transfers would need one such call plus a call per new incoming tx to get that other data.

florida.haunted
Full Member
***
Offline Offline

Activity: 210
Merit: 124


View Profile
February 09, 2015, 02:05:43 PM
 #19748

Ultimately we aren't preventing anyone from writing an additional implementation and submitting a PR, and we will at the very least have a BerkleyDB fall-back implementation for environments that don't play well with large MMAPs.

Hmm... BerkleyDB is a typo? Bitcoin itself had migrated from BerkleyDB to LevelDB...
fluffypony
Donator
Legendary
*
Offline Offline

Activity: 1260
Merit: 1024


GetMonero.org / MyMonero.com


View Profile WWW
February 09, 2015, 02:53:34 PM
 #19749

Ultimately we aren't preventing anyone from writing an additional implementation and submitting a PR, and we will at the very least have a BerkleyDB fall-back implementation for environments that don't play well with large MMAPs.

Hmm... BerkleyDB is a typo? Bitcoin itself had migrated from BerkleyDB to LevelDB...


Nope, not a typo. BerkleyDB's API is extremely close to LMDB's, so building that implementation will be somewhat trivial. The primary reason Bitcoin moved from BerkleyDB to LevelDB was due to BDB not guaranteeing binary compatibility between releases (point or otherwise), but as we've extrapolated away from the implementation and have to provide a cross-implementation conversion tool we don't really have to worry about this (also, we lock DB implementation versions and other consensus-critical components in by having the source in-tree and forcing static linking to it, that way we don't have to worry about consensus issues when someone upgrades something else on their system).

numismatist
Legendary
*
Offline Offline

Activity: 1179
Merit: 1000



View Profile
February 09, 2015, 02:55:48 PM
 #19750

Ultimately we aren't preventing anyone from writing an additional implementation and submitting a PR, and we will at the very least have a BerkleyDB fall-back implementation for environments that don't play well with large MMAPs.

Hmm... BerkleyDB is a typo? Bitcoin itself had migrated from BerkleyDB to LevelDB...

Meanwhiles, on http://coinmarketcap.com/currencies/views/filter-non-mineable-and-premined/ MonaCoin gets ready to buypass Monero, just mentioning. Rises 9.20 % whereas Monero does -7.17 %

fluffypony
Donator
Legendary
*
Offline Offline

Activity: 1260
Merit: 1024


GetMonero.org / MyMonero.com


View Profile WWW
February 09, 2015, 02:58:39 PM
 #19751

Code:
get_bulk_payments(json_encode(array('min_block_height'=>399206)));

When can we expect this function to work with only min_block_height parameter in the pre-built libraries?

That's not really on our radar; get_bulk_payments is for scanning payment IDs you already know. A general scan of the wallet would be using the incoming_transfers call.

get_bulk_payments does give information like block height/payment id for the incoming tx (which you want to know if you want to wait for N confirmations before crediting), and has a min_block_height which hte other doesn't. So using incoming_transfers would need one such call plus a call per new incoming tx to get that other data.

What I mean is that we won't be providing a get_bulk_payments call that doesn't take a list of payment IDs (at this stage). We are designing a successor to the payment ID protocol, but typically speaking you will still need to know what you're scanning for (whether it is a payment ID "generated" by the recipient or one given to the recipient by the sender).

GingerAle
Legendary
*
Offline Offline

Activity: 1176
Merit: 1004


View Profile WWW
February 09, 2015, 05:19:22 PM
 #19752

Ultimately we aren't preventing anyone from writing an additional implementation and submitting a PR, and we will at the very least have a BerkleyDB fall-back implementation for environments that don't play well with large MMAPs.

Hmm... BerkleyDB is a typo? Bitcoin itself had migrated from BerkleyDB to LevelDB...

Meanwhiles, on http://coinmarketcap.com/currencies/views/filter-non-mineable-and-premined/ MonaCoin gets ready to buypass Monero, just mentioning. Rises 9.20 % whereas Monero does -7.17 %

https://www.allcoin.com/trade/MONA_BTC

p.n.d.

< Track your bitcoins! > < Track them again! > <<< [url=https://www.reddit.com/r/Bitcoin/comments/1qomqt/what_a_landmark_legal_case_from_mid1700s_scotland/] What is fungibility? >>> 46P88uZ4edEgsk7iKQUGu2FUDYcdHm2HtLFiGLp1inG4e4f9PTb4mbHWYWFZGYUeQidJ8hFym2WUmWc p34X8HHmFS2LXJkf <<< Free subdomains at moneroworld.com!! >>> <<< If you don't want to run your own node, point your wallet to node.moneroworld.com, and get connected to a random node! @@@@ FUCK ALL THE PROFITEERS! PROOF OF WORK OR ITS A SCAM !!! @@@@
David Latapie
Hero Member
*****
Offline Offline

Activity: 658
Merit: 500


Monero Core Team


View Profile WWW
February 09, 2015, 06:01:15 PM
Last edit: February 09, 2015, 06:32:54 PM by David Latapie
 #19753

I see one use of multiple addresses: when you don't want to know that two transactions go to the same address (like if you don't want people to find you by googling your address which is on bitcointalk signature of profile, or openalias, for instance).
But since there is no much of these needs, you may as well just use a second wallet.

It doesn't matter if your address is known, as it's impossible (with our current cryptography) to analyse the blockchain and find transactions you were involved in. Even if that was possible it still wouldn't be disastrous, as all that can be observed are transactions you *may or may not* have been involved in (thanks to ring signatures). The only time multiple wallets are necessary are for separating your personal and business accounts, for instance, or for a company that wants each department to have its own address and accounts.
I was more thinking about the same address being a signature on weloveteddybears.com and gunenthusiast.com.

Pippo, to decide about Monero:

1. Follow this link: https://xmrmonero.com/faq/en/monero-matters
2. Follow all the links (some are just one post to read,not the whole thread)

If you are interested in the vision and the philosophy of the dev team, I recommand you "Three Pillars of Monero" if you want to know about the vision and spirit
If you are more interested in "Monero vs Darkcoin", read my comment on "Darkcoin, Anoncoin, Shadowcash, Monero"

You should have a good summary. We are working on creating a more consolidated document.

Monero: the first crytocurrency to bring bank secrecy and net neutrality to the blockchain.HyperStake: pushing the limits of staking.
Reputation threadFree bitcoins: reviews, hints…: freebitco.in, freedoge.co.in, qoinpro
smooth
Legendary
*
Offline Offline

Activity: 2002
Merit: 1065



View Profile
February 09, 2015, 08:46:59 PM
 #19754

I was more thinking about the same address being a signature on weloveteddybears.com and gunenthusiast.com.

It would certainly be a good idea for those to use different addresses, except perhaps in the case where they are both using third party payment processor, in which case sharing an address (with each other but also with many other businesses using the same payment processor) wouldn't mean anything at all.

TheKoziTwo
Legendary
*
Offline Offline

Activity: 1547
Merit: 1001



View Profile
February 09, 2015, 08:53:58 PM
 #19755

Code:
get_bulk_payments(json_encode(array('min_block_height'=>399206)));

When can we expect this function to work with only min_block_height parameter in the pre-built libraries?

That's not really on our radar; get_bulk_payments is for scanning payment IDs you already know. A general scan of the wallet would be using the incoming_transfers call.
I would like to make the application scalable, what is the best practice currently?

Getting transactions with incoming_transfers is fine, except the returned result will grow too large at some point? I guess with the parameter transfer_type "available" it won't be all that bad since most funds will be transferred elsewhere, but doesn't feel right to me. Also, is there any function to retrieve a payment_id with tx hash? without that this won't work anyways.

Polling get_bulk_payments with payment id's is fine too, except it will also grow too large at some point? As in, one may end up having to poll millions of payment ids. You could add the height parameter, but still, it just doesn't feel right having to run this through all payment_ids just to check for new transactions.

I'm thinking a simple get tx's/payment id's > height = new transactions for script to process.

Currently is seems to me I'll have to:
1. Record last checked height next to all payment ids in database.
2. Cron job traverse through all payment ids in database continuously checking for new tx's while also updating height

I must be missing something

smooth
Legendary
*
Offline Offline

Activity: 2002
Merit: 1065



View Profile
February 09, 2015, 08:56:46 PM
 #19756

Code:
get_bulk_payments(json_encode(array('min_block_height'=>399206)));

When can we expect this function to work with only min_block_height parameter in the pre-built libraries?

That's not really on our radar; get_bulk_payments is for scanning payment IDs you already know. A general scan of the wallet would be using the incoming_transfers call.
I would like to make the application scalable, what is the best practice currently?

Getting transactions with incoming_transfers is fine, except the returned result will grow too large at some point?

Maybe add an optional minimum height to incoming_transfers?
TheKoziTwo
Legendary
*
Offline Offline

Activity: 1547
Merit: 1001



View Profile
February 09, 2015, 09:00:49 PM
 #19757

Code:
get_bulk_payments(json_encode(array('min_block_height'=>399206)));

When can we expect this function to work with only min_block_height parameter in the pre-built libraries?

That's not really on our radar; get_bulk_payments is for scanning payment IDs you already know. A general scan of the wallet would be using the incoming_transfers call.
I would like to make the application scalable, what is the best practice currently?

Getting transactions with incoming_transfers is fine, except the returned result will grow too large at some point?

Maybe add an optional minimum height to incoming_transfers?

There is no such param atm afaik? Also that still leaves the other question, what function to get payment id from tx_id

smooth
Legendary
*
Offline Offline

Activity: 2002
Merit: 1065



View Profile
February 09, 2015, 09:08:32 PM
 #19758

Code:
get_bulk_payments(json_encode(array('min_block_height'=>399206)));

When can we expect this function to work with only min_block_height parameter in the pre-built libraries?

That's not really on our radar; get_bulk_payments is for scanning payment IDs you already know. A general scan of the wallet would be using the incoming_transfers call.
I would like to make the application scalable, what is the best practice currently?

Getting transactions with incoming_transfers is fine, except the returned result will grow too large at some point?

Maybe add an optional minimum height to incoming_transfers?

There is no such param atm afaik?

Yes, that's why I proposed adding one.

Quote
Also that still leaves the other question, what function to get payment id from tx_id

There doesn't seem to be one right now. You can get the tx in raw hex but you would have to decode it.

BTW, as far as I can tell from the code, if you do get_bulk_payments with an empty payment ID list you get all payments.

David Latapie
Hero Member
*****
Offline Offline

Activity: 658
Merit: 500


Monero Core Team


View Profile WWW
February 09, 2015, 09:51:02 PM
 #19759

I significantly updated the FAQ entry for OpenAlias

New entry is https://xmrmonero.com/faq/openalias
The text is the one from www.http://reddit.com/r/Monero/comments/2uv214/what_is_openalias/ with some extras
1. Step-by-step instructions on how to create your own alias (as requested on the Monero forum) and link to saddam's giveaway
2. Creating an OpenAlias for another cryptocurrency
3. OpenAlias and .bit (Namecoin), including a hint for those who don't have a domain name and don't want to spend several euros per year just for that

Monero: the first crytocurrency to bring bank secrecy and net neutrality to the blockchain.HyperStake: pushing the limits of staking.
Reputation threadFree bitcoins: reviews, hints…: freebitco.in, freedoge.co.in, qoinpro
TheKoziTwo
Legendary
*
Offline Offline

Activity: 1547
Merit: 1001



View Profile
February 09, 2015, 11:29:27 PM
 #19760

Code:
get_bulk_payments(json_encode(array('min_block_height'=>399206)));

When can we expect this function to work with only min_block_height parameter in the pre-built libraries?

That's not really on our radar; get_bulk_payments is for scanning payment IDs you already know. A general scan of the wallet would be using the incoming_transfers call.
I would like to make the application scalable, what is the best practice currently?

Getting transactions with incoming_transfers is fine, except the returned result will grow too large at some point?

Maybe add an optional minimum height to incoming_transfers?

There is no such param atm afaik?

Yes, that's why I proposed adding one.
I would prefer to have minimum height implemented in get_bulk_payments so that you do not have to enter payment id's.

Quote
Also that still leaves the other question, what function to get payment id from tx_id

There doesn't seem to be one right now. You can get the tx in raw hex but you would have to decode it.

BTW, as far as I can tell from the code, if you do get_bulk_payments with an empty payment ID list you get all payments.


I thought so at first too, but it doesn't work, I have to specify payment id's otherwise nothing is returned...

Code:
Code:
$r = $wallet->get_bulk_payments(json_encode(array('payment_ids'=>array())));
var_dump($r);

$r = $wallet->get_bulk_payments(json_encode(array('min_block_height'=>399206)));
var_dump($r);

$r = $wallet->get_bulk_payments(json_encode(array('payment_ids'=>array(),'min_block_height'=>399206)));
var_dump($r);

$r = $wallet->get_bulk_payments(json_encode(array('payment_ids'=>null)));
var_dump($r);

$r = $wallet->get_bulk_payments(json_encode(array('payment_ids'=>null,'min_block_height'=>399206)));
var_dump($r);

Result:
Code:
array (size=0)
  empty

array (size=0)
  empty

array (size=0)
  empty

array (size=0)
  empty

array (size=0)
  empty

Pages: « 1 ... 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 [988] 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 ... 2030 »
  Print  
 
Jump to:  

Bitcointalk.org is not available or authorized for sale. Do not believe any fake listings.
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!